Data processing method and device for educational software, electronic equipment and storage medium

Abstract

The application provides a data processing method and device of educational software, electronic equipment and a storage medium, and relates to the technical field of data processing. The method comprises the following steps: obtaining original data packets generated when a target educational software runs, wherein the original data packets at least comprise context parameters, and the context parameters comprise called algorithm identifiers, input parameters and output results; preprocessing the original data packets to generate algorithm data records; extracting structured algorithm archives of at least one algorithm to be verified from the algorithm data records, wherein the structured algorithm archives comprise static attribute information, dynamic running characteristics and model attribute information; performing risk assessment on the structured algorithm archives of each algorithm, determining risk scores of each algorithm, and performing differentiated hierarchical storage on the structured algorithm archives of the algorithms based on the risk scores of the algorithms, so that the whole-process traceability of algorithm behaviors in the educational software is realized, and the algorithm transparency is enhanced.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a data processing method, apparatus, electronic device, and storage medium for educational software. Background Technology

[0002] With the deepening application of artificial intelligence technology in education, intelligent educational software (such as personalized learning applications and adaptive assessment systems) has become widely used. The core of this type of software lies in its built-in algorithmic models, such as collaborative filtering or deep learning models for exercise recommendation and knowledge tracking models for student ability assessment. These algorithms analyze user behavior data to provide personalized teaching services, greatly improving learning efficiency.

[0003] To support continuous iterative optimization of algorithms, ensure fairness and transparency in the decision-making process, and meet increasingly stringent regulatory requirements, the efficient and secure collection and storage of data generated during algorithm operation has become a crucial and fundamental aspect. Therefore, how to achieve efficient and secure data collection and storage is an urgent problem to be solved. Summary of the Invention

[0004] The purpose of this application is to address the shortcomings of the prior art by providing a data processing method, apparatus, electronic device, and storage medium for educational software, so as to solve the technical problems existing in the prior art.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a data processing method for educational software, the method comprising: Obtain the raw data packet generated by the target educational software during runtime. The raw data packet includes at least: context parameters, which include the algorithm identifier being called, input parameters, and output results. The original data packet is preprocessed to generate algorithm data records; Extract a structured algorithm file of at least one algorithm to be verified from the algorithm data record. The structured algorithm file includes: static attribute information, dynamic running features and model attribute information. A risk assessment is performed on the structured algorithm files of each algorithm to determine the risk score of each algorithm, and the structured algorithm files of each algorithm are stored in a differentiated hierarchical manner based on the risk scores of the algorithms.

[0006] Optionally, obtaining the raw data packets generated during the runtime of the target educational software includes: The raw data packets generated during the runtime of the target educational software are obtained by using data tracking.

[0007] Optionally, the step of acquiring the raw data packets generated during the runtime of the target educational software using data tracking includes: Obtain the pre-generated data acquisition code; The data acquisition code is embedded into the key interactive nodes and / or backend service interfaces of the target educational software; When a predefined trigger event is detected, the data acquisition code captures the raw data packet associated with the trigger event. The trigger event includes at least one of the following: algorithm call event, algorithm execution parameter event, algorithm output event, and user feedback event.

[0008] Optionally, the preprocessing of the original data packet to generate algorithm data records includes: Integrity verification is performed on each key field in the original data packet to obtain verified data. The verified data is then converted into a predefined standard data structure to obtain the algorithm data record.

[0009] Optionally, extracting the structured algorithm archive of at least one algorithm to be tested from the algorithm data record includes: Based on the algorithm identifier in the algorithm data record, the static metadata of the algorithm is obtained by querying. The static metadata includes at least: algorithm type, model architecture, deployment environment, and current active version number. Based on the input parameters and output results in the algorithm data record, the dynamic running characteristics of the algorithm are extracted. The dynamic running characteristics include: input characteristics, output characteristics, and execution characteristics. Based on the algorithm identifier in the algorithm data record, the model attribute information of the algorithm is determined. The model attribute information includes: the algorithm model version number and the associated record of the training dataset used.

[0010] Optionally, the risk assessment of the structured algorithm files for each of the algorithms, and the determination of the risk score for each algorithm, includes: Based on the associated records of the training dataset used in the model attribute information, the baseline features during algorithm training are determined; Determine the feature similarity between the input features in the dynamic operation features and the baseline features. If the feature similarity exceeds a preset similarity threshold, then determine the data drift risk score of the algorithm. Determine the output features in the dynamic operation features, and determine the model accuracy score of the algorithm; The latency anomaly score of the algorithm is determined based on the execution characteristics in the dynamic operation characteristics. Based on a preset risk weighting model, the data drift risk score, the model accuracy score, and the latency anomaly score are weighted and summed to obtain the risk score of the algorithm.

[0011] Optionally, the step of differentially hierarchically storing the structured algorithm archive based on the risk score of the algorithm includes: If the risk score of the algorithm is greater than or equal to the first threshold, the risk level of the algorithm is determined to be the first risk level, and the structured algorithm file of the algorithm is stored in a high-performance SSD database. If the risk score of the algorithm is less than the first threshold, the risk level of the algorithm is determined to be the second risk level or the third risk level, and the structured algorithm file of the algorithm is stored in the pre-built data lake, wherein the risk of the first risk level is higher than the risk of the second risk level, and the risk of the second risk level is higher than the risk of the third risk level.

[0012] Secondly, embodiments of this application also provide a data processing apparatus for educational software, the apparatus comprising: The acquisition module is used to acquire the raw data packets generated by the target educational software during runtime. The raw data packets include at least: context parameters, which include the algorithm identifier being called, input parameters, and output results. The processing module is used to preprocess the original data packet to generate algorithm data records; The extraction module is used to extract a structured algorithm file of at least one algorithm to be verified from the algorithm data record. The structured algorithm file includes: static attribute information, dynamic running features, and model attribute information. The evaluation module is used to perform risk assessment on the structured algorithm files of each of the algorithms and determine the risk score of each algorithm. The storage module is used to perform differentiated hierarchical storage of the structured algorithm archive based on the risk score of the algorithm.

[0013] Optionally, the acquisition module is specifically used for: The raw data packets generated during the runtime of the target educational software are obtained by using data tracking.

[0014] Optionally, the acquisition module is specifically used for: Obtain the pre-generated data acquisition code; The data acquisition code is embedded into the key interactive nodes and / or backend service interfaces of the target educational software; When a predefined trigger event is detected, the data acquisition code captures the raw data packet associated with the trigger event. The trigger event includes at least one of the following: algorithm call event, algorithm execution parameter event, algorithm output event, and user feedback event.

[0015] Optionally, the processing module is specifically used for: Integrity verification is performed on each key field in the original data packet to obtain verified data. The verified data is then converted into a predefined standard data structure to obtain the algorithm data record.

[0016] Optionally, the extraction module is specifically used for: Based on the algorithm identifier in the algorithm data record, the static metadata of the algorithm is obtained by querying. The static metadata includes at least: algorithm type, model architecture, deployment environment, and current active version number. Based on the input parameters and output results in the algorithm data record, the dynamic running characteristics of the algorithm are extracted. The dynamic running characteristics include: input characteristics, output characteristics, and execution characteristics. Based on the algorithm identifier in the algorithm data record, the model attribute information of the algorithm is determined. The model attribute information includes: the algorithm model version number and the associated record of the training dataset used.

[0017] Optionally, the evaluation module is specifically used for: Based on the associated records of the training dataset used in the model attribute information, the baseline features during algorithm training are determined; Determine the feature similarity between the input features in the dynamic operation features and the baseline features. If the feature similarity exceeds a preset similarity threshold, then determine the data drift risk score of the algorithm. Determine the output features in the dynamic operation features, and determine the model accuracy score of the algorithm; The latency anomaly score of the algorithm is determined based on the execution characteristics in the dynamic operation characteristics. Based on a preset risk weighting model, the data drift risk score, the model accuracy score, and the latency anomaly score are weighted and summed to obtain the risk score of the algorithm.

[0018] Optionally, the storage module is specifically used for: If the risk score of the algorithm is greater than or equal to the first threshold, the risk level of the algorithm is determined to be the first risk level, and the structured algorithm file of the algorithm is stored in a high-performance SSD database. If the risk score of the algorithm is less than the first threshold, the risk level of the algorithm is determined to be the second risk level or the third risk level, and the structured algorithm file of the algorithm is stored in the pre-built data lake, wherein the risk of the first risk level is higher than the risk of the second risk level, and the risk of the second risk level is higher than the risk of the third risk level.

[0019] Thirdly, embodiments of this application provide an electronic device, which includes a memory for storing one or more programs and a processor. When the one or more programs are executed by the processor, the data processing method of the educational software described above is implemented.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the data processing method of the educational software described above.

[0021] The beneficial effects of this application are: This application provides a data processing method, apparatus, electronic device, and storage medium for educational software. First, it acquires the raw data packets generated during the runtime of the target educational software. These raw data packets include at least the identifier of the invoked algorithm, input parameters, and output results, achieving high-fidelity, fine-grained data collection throughout the algorithm's entire lifecycle. Then, it preprocesses the raw data packets to generate algorithm data records and extracts a structured algorithm file for at least one algorithm to be verified from these records. The structured algorithm file includes static attribute information, dynamic operational characteristics, and model attribute information, thus completely recording the algorithm's static attribute information, dynamic operational characteristics, and model attribute information, thoroughly breaking down the "algorithm black box" and providing a solid data foundation for algorithm fairness review and accountability. Multi-dimensional risk assessments are performed on the structured algorithm files of each algorithm to obtain a risk score for each algorithm, ensuring the fairness and rationality of algorithm evaluation. Based on the algorithm's risk score, the structured algorithm files are stored in a differentiated, layered manner, avoiding the high costs of a "one-size-fits-all" full-data storage approach, significantly reducing storage overhead, ensuring the security of key data, and meeting regulatory inspection requirements. This achieves full traceability of algorithm behavior in educational software and enhances the transparency of algorithm operation.

[0022] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating a data processing method for educational software provided in an embodiment of this application; Figure 2 A flowchart illustrating another data processing method for educational software provided in an embodiment of this application; Figure 3 A flowchart illustrating another data processing method for educational software provided in this application embodiment; Figure 4 A flowchart illustrating another data processing method for educational software provided in an embodiment of this application; Figure 5 A flowchart illustrating another data processing method for educational software provided in this application embodiment; Figure 6 A flowchart illustrating a data processing device for educational software provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0026] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0027] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0028] Please see Figure 1 , Figure 1This application provides a data processing method for educational software. The executing entity of this method can be an electronic device with data processing capabilities, such as a computer, server, or smartphone. Figure 1 As shown, the method includes: S101. Obtain the raw data packets generated by the target educational software during runtime.

[0029] The original data packet includes at least the following: context parameters, which include the algorithm identifier ID, input parameters, and output results.

[0030] Optionally, the raw data packet is an unstructured or semi-structured collection of data, and may also contain the following key information: event name, timestamp, user identifier, and session identifier.

[0031] The event name refers to the type of event that is currently being triggered (e.g., AI_Recommendation_Called). Timestamp: The time when the currently triggered event occurred, accurate to the millisecond level; User ID: Identifies the user who performed the operation; Session ID: Identifies the current session in which the user is continuously using the software.

[0032] For example, targeted educational software can be intelligent recommendation systems, adaptive learning platforms, AI-powered homework grading, etc.

[0033] In one feasible approach, during the operation of the target educational software, when a user completes a predefined interactive action (such as clicking, swiping, or inputting) within the target educational software, or when the system background completes an algorithm calculation, the raw data packets associated with the event can be immediately captured through methods such as data tracking, API interception, and log monitoring.

[0034] Alternatively, the raw data packets can be reported to the processing module asynchronously through a background queue to ensure that the data collection process does not block the main business process of the educational software and to protect the user experience.

[0035] S102. Preprocess the raw data packet to generate algorithm data records.

[0036] For example, preprocessing may include: denoising, completion, normalization, correlation, etc.

[0037] Among them, clear noise removal: removes data with null values, duplicates, and abnormal codes (such as test requests and empty inputs). Field completion: Supplement missing fields (e.g., inferring upstream algorithms through call chains); Standardize the format: unify units and encoding formats (such as JSON Schema validation); Association: Establish a cross-algorithm call relationship graph (e.g., the output of algorithm A is used as the input of algorithm B).

[0038] Optionally, to improve processing efficiency, the original data packets can be preprocessed to convert them into algorithm data records in a uniform format, which can then be used as input for subsequent algorithm feature extraction and version management.

[0039] S103. Extract a structured algorithm archive of at least one algorithm to be verified from the algorithm data record.

[0040] The structured algorithm file includes: static attribute information, dynamic running characteristics, and model attribute information.

[0041] Optionally, static attribute information includes: algorithm type, model description, deployment environment, and currently activated version; Dynamic operation characteristics include: input characteristics, output characteristics, and execution characteristics.

[0042] Input features refer to the input vectors used by the model for prediction, such as students' historical answer sequences and knowledge mastery levels; output features refer to the model's prediction results, such as prediction accuracy, recommendation item IDs, and confidence scores; execution features refer to non-functional metrics during algorithm runtime, such as latency, CPU / GPU utilization, and memory consumption.

[0043] Model attribute information includes the model version number and the identifier of the training dataset used, so as to trace the life cycle of the algorithm based on the model attribute information and to conduct subsequent data drift analysis.

[0044] In this embodiment, the context parameters in the algorithm data record can be parsed to obtain the static attribute information, dynamic running characteristics, and model attribute information of at least one algorithm to be verified. For example, based on the called algorithm identifier in the context parameters, the static attribute information of the algorithm can be found from the pre-built algorithm registry center, such as the current active version of algorithm A being v1.7.2 and the model description being the model framework used, PyTorch, etc. Based on the static attribute information, dynamic running characteristics, and model attribute information of algorithm A, the structured algorithm file of algorithm A can be obtained, and the structured algorithm files of all algorithms can be output in a unified JSON or Protobuf format.

[0045] S104. Conduct a risk assessment on the structured algorithm files of each algorithm, determine the risk score of each algorithm, and store the structured algorithm files of the algorithms in a differentiated hierarchical manner based on the risk scores of the algorithms.

[0046] In one feasible approach, to conduct a comprehensive risk assessment of an algorithm, a risk score for the algorithm can be obtained based on the algorithm's structured algorithm profile, which includes multiple dimensions such as data drift score, execution performance score, and model metric score. The risk scores under each dimension are then weighted and summed to obtain the algorithm's overall risk score, thus achieving fairness and reasonableness in the algorithm evaluation.

[0047] Optionally, considering that most existing educational software stores user data on servers that do not meet security standards, or even on overseas servers, posing a risk of data leakage and illegal transfer, this embodiment proposes to adopt different data storage strategies based on the risk score of the algorithm. For example, if the risk score of algorithm A is high, the structured algorithm file of algorithm A is stored in a high-performance SSD database, accessible only to the "data security" role. It also supports on-demand decompression and backtracking, meeting regulatory inspection requirements and achieving full traceability of algorithm behavior in educational software, enhancing algorithm transparency and accountability. Therefore, in this embodiment, differentiated layered storage avoids the high costs of a "one-size-fits-all" full-data storage approach, significantly reducing storage overhead while ensuring the security of critical data.

[0048] Therefore, in this embodiment, different differentiated tiered storage strategies and access requirements are implemented based on the risk scores of all algorithms, and strict access control and encryption mechanisms are used to ensure data security, traceability, and efficient use of storage resources.

[0049] This module utilizes modern cloud storage technology and a data lake architecture to provide highly elastic, secure, and low-cost storage services. Specifically, it receives algorithm files and obtains a comprehensive risk score (i.e., hot / warm / cold risk classification). End-to-end encryption is implemented before data is written to the storage medium. This ensures that data is encrypted both during transmission and at rest, meeting the highest security standards. A role-based access control model can be deployed to define fine-grained permissions, ensuring that only users with the appropriate roles can access specific levels of data. For example, high-risk (hot) data might only be accessible to algorithm maintenance and security auditors.

[0050] Optionally, distributed management technologies can be used to ensure efficient allocation of storage resources and high system availability, such as using a distributed hash table mechanism. Each algorithm file is assigned a unique identifier upon writing and mapped to a specific node in the storage system according to a hash function, achieving even data distribution and avoiding single points of failure. The load of each storage node (including available space, read / write speed, and network latency) is monitored in real time. When data is written, the system dynamically selects the node with the lowest load and best performance for storage based on the current load of the storage nodes. When the load of a node exceeds a preset threshold, a load balancing process is automatically initiated, migrating some data to other low-load nodes. When a storage node needs to be taken offline, the system will preemptively migrate the data completely to other nodes to ensure data continuity.

[0051] In summary, this application provides a data processing method for educational software. First, the raw data packets generated during the runtime of the target educational software are obtained. These raw data packets include at least the identifier of the invoked algorithm, input parameters, and output results. Then, the raw data packets are preprocessed to generate algorithm data records. From these records, structured algorithm files for at least one algorithm to be verified are extracted. These structured algorithm files include static attribute information, dynamic operational characteristics, and model attribute information. A multi-dimensional risk assessment is performed on the structured algorithm files of each algorithm to obtain a risk score for each algorithm, ensuring fairness and reasonableness in algorithm evaluation. Based on the risk scores, the structured algorithm files are stored in a differentiated, layered manner, avoiding the high costs associated with a "one-size-fits-all" approach to full data storage, significantly reducing storage overhead, ensuring the security of critical data, and meeting regulatory inspection requirements. This achieves full traceability of algorithm behavior in the educational software and transparency in algorithm operation.

[0052] Optionally, step S101 above includes: The raw data packets generated during the runtime of the target educational software are obtained by using data tracking.

[0053] In one feasible approach, data tracking points are deployed along the critical execution path of the target educational software. During the operation of the target educational software, context parameters of each algorithm or functional module are captured in real time, and structured raw data packets are generated based on the context parameters to provide basic data support for subsequent risk assessment.

[0054] Optionally, refer to Figure 2 As shown, the above steps use data tracking to obtain the raw data packets generated during the runtime of the target educational software, including: S201. Obtain the pre-generated data acquisition code.

[0055] For example, data collection code can be manually written by developers and directly embedded into the target educational software without affecting its normal operation.

[0056] S202. Embed the data acquisition code into the key interactive nodes and / or backend service interfaces of the target educational software.

[0057] Key interactive nodes can be user interface elements and backend service interfaces provided by the educational software. For example, user interface elements can include click buttons, swipe buttons, input buttons, etc., and backend service interfaces can include page loading and page switching.

[0058] S203. When a predefined trigger event is detected, the raw data packet associated with the trigger event is captured by the data acquisition code.

[0059] The triggering events include at least one of the following: algorithm call event, algorithm execution parameter event, algorithm output event, and user feedback event.

[0060] The algorithm call event can trigger the call of the recommendation algorithm when the user clicks the "Smart Recommended Exercises" button.

[0061] Algorithm execution parameter events can record key parameters such as input data, user history, and environment configuration during algorithm execution.

[0062] Algorithm output events record the results of the algorithm's execution, such as a list of recommended exercises, a personalized learning path, or error diagnosis results.

[0063] User feedback events are explicit feedback from users to the algorithm results, such as clicking "dislike" on recommendations or giving a rating.

[0064] In one feasible approach, data collection code (i.e., event tracking) is embedded into key interactive nodes and / or backend service interfaces of the target educational software. When a specific "trigger event" (such as clicking a button, page loading, or background calculation completion) is triggered, the corresponding event tracking is activated, i.e., the raw data packets associated with the trigger event are captured through the data collection code. Therefore, in this embodiment, data is collected only when key events occur during the data collection process, avoiding the proliferation of invalid data.

[0065] In this embodiment, by using "data collection points" and "event design", this solution can accurately associate data collection points with key events such as algorithm input, execution and output, rather than relying solely on coarse-grained system logs. This achieves refined and high-fidelity data collection, providing the most accurate raw data for subsequent algorithm analysis and fault diagnosis.

[0066] In this process, the data collection will not block the main business process of the educational software, thus ensuring a good user experience.

[0067] Optionally, step S102 above includes: Integrity verification is performed on each key field in the original data packet to obtain verified data. The verified data is then converted into a predefined standard data structure to obtain the algorithm data record.

[0068] In this embodiment, the raw data packets described above are cleaned and standardized. Specifically, the received raw data packets undergo an integrity check to ensure that all required fields are present and correctly formatted. Missing or incorrectly formatted data is marked and processed according to preset rules (such as discarding or filling in default values). Then, the raw data from different educational software modules, which may have different log formats, is uniformly converted into a standard data structure defined internally by the system (e.g., a unified JSON Schema). Therefore, through the preprocessing in this embodiment, the raw, scattered algorithm information can be transformed into standard algorithm data records that can be directly parsed.

[0069] Optionally, refer to Figure 3 As shown, step S103 above includes: S301. Based on the algorithm identifier in the algorithm data record, retrieve the static metadata of the algorithm.

[0070] Static metadata includes at least the following: algorithm type, model architecture, deployment environment, and current active version number.

[0071] In one feasible approach, the algorithm data record is first schema-validated to ensure that all key fields (such as Event Name, Timestamp, Algorithm_ID) conform to predefined data structure standards. Then, using the algorithm identifier Algorithm_ID of the algorithm data record, the static metadata of the algorithm is retrieved from a pre-built model registry (such as MLflow ModelRegistry or Amazon SageMaker Model Registry), including: algorithm type, model architecture, deployment environment, and current active version number.

[0072] The algorithm types include recommendation models, knowledge tracking models, and evaluation models.

[0073] The model description is the model architecture used, such as Transformer or LSTM.

[0074] The deployment environment includes: service name and deployment region.

[0075] The currently active version is used to cross-validate whether the version in the data is correct.

[0076] S302. Based on the input parameters and output results in the algorithm data record, extract the dynamic running characteristics of the algorithm during runtime.

[0077] The dynamic operation characteristics include: input characteristics, output characteristics, and execution characteristics.

[0078] In this embodiment, feature engineering and metadata extraction are performed based on the input parameters and output results in the algorithm data record. For example, dynamic running features related to the algorithm operation are extracted. Dynamic running features include: input features, output features, and execution features.

[0079] Input features refer to the input vectors used by the model for prediction, such as students' historical answer sequences and knowledge mastery levels.

[0080] Output features refer to the model's prediction results, such as prediction accuracy, recommendation ID, and confidence score.

[0081] Execution characteristics refer to non-functional metrics during algorithm runtime, such as latency, CPU / GPU utilization, and memory consumption.

[0082] Optionally, users can interact with the online Feature Store. Interacting with the Feature Store pushes the collected input and output features to it. The Feature Store ensures that the feature format and definitions used in this prediction are completely consistent with those used during model training, thus minimizing training-service bias and significantly reducing its risk, thereby improving the reliability and accuracy of the model in real-world operation. For certain features requiring real-time aggregation calculations (such as the average answering speed over the past 5 minutes), the Feature Store can provide low-latency real-time calculation results as a supplement to the algorithm archive.

[0083] S303. Determine the model attribute information of the algorithm based on the algorithm identifier in the algorithm data record.

[0084] The model attribute information includes: the algorithm model version number and the associated records of the training dataset used.

[0085] In this embodiment, the algorithm identifier (Algorithm_ID) recorded in the algorithm data is used to query the algorithm's model attribute information, also known as lineage information, from a model registry (such as MLflow Model Registry or Amazon SageMaker Model Registry) to trace the algorithm's lifecycle. The model attribute information includes: the algorithm model version number and the identifier of the training dataset used. The algorithm model version number refers to recording the precise model version number, not just the major version; the training data association record records the training dataset ID or data shard hash value used by this version of the model for subsequent data drift analysis. The final algorithm profile is output in a unified JSON or Protobuf format, achieving complete lineage tracing for any algorithm decision and facilitating rapid identification of the root cause of algorithm performance degradation or anomalies.

[0086] Optionally, refer to Figure 4 As shown, step S104 above involves performing a risk assessment on the structured algorithm files of each algorithm to determine the risk score for each algorithm, including: S401. Determine the baseline features for algorithm training based on the associated records of the training dataset used in the model attribute information.

[0087] S402. Determine the feature similarity between the input features and the baseline features in the dynamic operation features. If the feature similarity exceeds the preset similarity threshold, determine the data drift risk score of the algorithm.

[0088] In one feasible approach, a structured algorithm archive is used to assess and classify the algorithm's health status, and to issue early warnings for high-risk events. Specifically, the baseline features of the algorithm during model training are obtained by utilizing the associated records of the training dataset used in the model attribute information. Statistical tests (such as the Kolmogorov-Smirnov Test or the Population Stability Index, PSI) are then used to calculate the feature similarity between the input features in the dynamically running features and the baseline features in real time. If the feature similarity exceeds a preset similarity threshold, it is marked as a data drift risk.

[0089] Optionally, statistical methods such as PSI / KS Test can be used to monitor the distribution changes of algorithm input features in real time and compare the model prediction results. This can detect and mark risks in advance before the model performance deteriorates significantly (i.e., in the early stage of model drift), minimizing the time to solve problems and enabling real-time risk control and intelligent early warning.

[0090] S403. Determine the output features in the dynamic operation features and determine the model accuracy score of the algorithm.

[0091] S404. Determine the latency anomaly score of the algorithm based on the execution characteristics in the dynamic operation characteristics.

[0092] Optionally, the output features in the dynamic running features can also be used to check whether the data integrity (such as missing rate, outliers) and data type meet expectations. For algorithms with immediate labels (such as immediately determining whether a user's answer is correct), the accuracy, recall, and other business metrics of the algorithm are monitored in real time to see if they are lower than the deviation of the A / B test or the baseline model. For algorithms without immediate labels (such as long-term learning path recommendation), the distribution of model confidence is monitored to see if there are significant changes. A decrease in confidence often indicates a decline in model performance, thus obtaining the model accuracy score of the algorithm. Based on the execution features in the dynamic running features (including prediction latency, error rate, and resource consumption), any sudden spikes or long-term trend declines will be marked to obtain the latency anomaly score of the algorithm.

[0093] S405. Based on the preset risk weighting model, the data drift risk score, model accuracy score, and latency anomaly score are weighted and summed to obtain the risk score of the algorithm.

[0094] In one feasible way, the risk score of the algorithm can be calculated by weighting and summing the data drift risk score, model accuracy score, and latency anomaly score based on a preset risk weighting model.

[0095] Optionally, refer to Figure 5 As shown, in step S104 above, based on the risk scoring of the algorithm, the structured algorithm file of the algorithm is stored in a differentiated and hierarchical manner, including: S501. If the risk score of the algorithm is greater than or equal to the first threshold, the risk level of the algorithm is determined to be the first risk level, and the structured algorithm file of the algorithm is stored in the high-performance SSD database.

[0096] For example, the first threshold is 0.8. If the risk score of algorithm A is greater than 0.8, then the risk level of algorithm A is determined to be the first risk level, i.e., a hot risk. An alert is immediately sent to notify the operations and maintenance personnel, and the algorithm is marked in the archive. All structured algorithm archives marked as hot risks are immediately written to a high-performance SSD database for millisecond-level querying and fault diagnosis by the operations and maintenance personnel. An alert is immediately sent to notify the operations and maintenance personnel, and the algorithm is marked in the archive.

[0097] S502. If the risk score of the algorithm is less than the first threshold, the risk level of the algorithm is determined to be the second risk level or the third risk level, and the structured algorithm file of the algorithm is stored in the pre-built data lake, wherein the risk of the first risk level is higher than the risk of the second risk level, and the risk of the second risk level is higher than the risk of the third risk level.

[0098] The first threshold can be dynamically adjusted based on the algorithm's historical fluctuations to reduce false alarms.

[0099] For example, if the risk score of the algorithm is between the second threshold and the first threshold, such as if the risk score of the algorithm is greater than 0.5 and less than 0.8, then the risk level of the algorithm will be determined as the second risk level, i.e., mild risk; if the risk score of the algorithm is less than the second threshold, then the risk level of the algorithm will be determined as the third risk level, i.e., cold risk.

[0100] In this embodiment, all structured algorithm files marked as warm / cold risk are written to a data lake (Apache Hudi, Delta Lake, etc.) and built on cloud object storage as a data lake for model retraining. Files in the data lake that have not been accessed for more than 90 days are automatically migrated to archive storage (such as ordinary hardware cold storage) through the cloud storage's lifecycle management strategy, minimizing costs. A distributed hash table mechanism is used to evenly distribute data across storage nodes, and node load is continuously monitored. When node load exceeds a threshold (e.g., exceeding 80% IOPS), a data migration process is automatically triggered to low-load nodes, ensuring high system availability and concurrent processing performance.

[0101] Therefore, in this embodiment, based on the risk scores of all algorithms, the structured algorithm archives are stored and securely controlled in a tiered manner. Before data is written, KMS service is used for key management, and AES-256 encryption is implemented. Access permissions are set, with only the "Data Security" role able to access the original input sequence of the hot data layer, and the "Algorithm Engineer" role able to access the feature indicators of the warm / cold data layers. This effectively balances data access performance and storage costs, allowing for immediate access to high-risk data and minimizing the cost of low-risk archived data, aligning with long-term operational economic benefits. Furthermore, by adopting distributed hash table mechanisms and intelligent load balancing, even data distribution and elastic scaling of storage nodes are achieved, improving the system's high availability and concurrent processing capabilities. A cold data rewarming mechanism is also supported, ensuring that historical data with increased access frequency can be automatically migrated to the high-performance layer, guaranteeing data continuity. End-to-end encryption (in transmission and at rest) and a role-based access control model are implemented. This ensures the highest level of security for algorithms and student privacy data, with only authorized personnel able to access data at the corresponding risk level, meeting educational data compliance requirements.

[0102] Optionally, refer to Figure 6 The diagram shown is a structural schematic of a data processing device for educational software provided in an embodiment of this application. The device includes: The acquisition module 601 is used to acquire the raw data packet generated by the target educational software during runtime. The raw data packet includes at least: context parameters, which include the algorithm identifier being called, input parameters, and output results. Processing module 602 is used to preprocess the original data packet to generate algorithm data records; Extraction module 603 is used to extract a structured algorithm file of at least one algorithm to be verified from the algorithm data record. The structured algorithm file includes: static attribute information, dynamic running features and model attribute information. The evaluation module 604 is used to perform a risk assessment on the structured algorithm files of each of the algorithms and determine the risk score of each of the algorithms. Storage module 605 is used to perform differentiated hierarchical storage of the structured algorithm file of the algorithm based on the risk score of the algorithm.

[0103] Optionally, the acquisition module 601 is specifically used for: The raw data packets generated during the runtime of the target educational software are obtained by using data tracking.

[0104] Optionally, the acquisition module 601 is specifically used for: Obtain the pre-generated data acquisition code; The data acquisition code is embedded into the key interactive nodes and / or backend service interfaces of the target educational software; When a predefined trigger event is detected, the data acquisition code captures the raw data packet associated with the trigger event. The trigger event includes at least one of the following: algorithm call event, algorithm execution parameter event, algorithm output event, and user feedback event.

[0105] Optionally, the processing module 602 is specifically used for: Integrity verification is performed on each key field in the original data packet to obtain verified data. The verified data is then converted into a predefined standard data structure to obtain the algorithm data record.

[0106] Optionally, the extraction module 603 is specifically used for: Based on the algorithm identifier in the algorithm data record, the static metadata of the algorithm is obtained by querying. The static metadata includes at least: algorithm type, model architecture, deployment environment, and current active version number. Based on the input parameters and output results in the algorithm data record, the dynamic running characteristics of the algorithm are extracted. The dynamic running characteristics include: input characteristics, output characteristics, and execution characteristics. Based on the algorithm identifier in the algorithm data record, the model attribute information of the algorithm is determined. The model attribute information includes: the algorithm model version number and the associated record of the training dataset used.

[0107] Optionally, the evaluation module 604 is specifically used for: Based on the associated records of the training dataset used in the model attribute information, the baseline features during algorithm training are determined; Determine the feature similarity between the input features in the dynamic operation features and the baseline features. If the feature similarity exceeds a preset similarity threshold, then determine the data drift risk score of the algorithm. Determine the output features in the dynamic operation features, and determine the model accuracy score of the algorithm; The latency anomaly score of the algorithm is determined based on the execution characteristics in the dynamic operation characteristics. Based on a preset risk weighting model, the data drift risk score, the model accuracy score, and the latency anomaly score are weighted and summed to obtain the risk score of the algorithm.

[0108] Optionally, the storage module 605 is specifically used for: If the risk score of the algorithm is greater than or equal to the first threshold, the risk level of the algorithm is determined to be the first risk level, and the structured algorithm file of the algorithm is stored in a high-performance SSD database. If the risk score of the algorithm is less than the first threshold, the risk level of the algorithm is determined to be the second risk level or the third risk level, and the structured algorithm file of the algorithm is stored in the pre-built data lake, wherein the risk of the first risk level is higher than the risk of the second risk level, and the risk of the second risk level is higher than the risk of the third risk level.

[0109] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.

[0110] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more digital signal processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0111] Figure 7 This application provides a schematic diagram of the structure of an electronic device, which can be a computing device with data processing capabilities.

[0112] The electronic device includes: processor 701 and memory 702.

[0113] The memory 702 is used to store programs, and the processor 701 calls the programs stored in the memory 702 to execute the above method embodiments. The specific implementation and technical effects are similar, and will not be described again here.

[0114] Optionally, this application also provides a program product, such as a computer-readable storage medium, including a program that, when executed by a processor, performs the above-described method embodiments.

[0115] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0116] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0117] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0118] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0119] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A data processing method for educational software, characterized in that, The method includes: Obtain the raw data packet generated by the target educational software during runtime, the raw data packet including at least: context parameters, the context parameters including the algorithm identifier being called, input parameters and output results; The original data packet is preprocessed to generate algorithm data records; Extract a structured algorithm file of at least one algorithm to be verified from the algorithm data record. The structured algorithm file includes: static attribute information, dynamic running features and model attribute information. A risk assessment is performed on the structured algorithm files of each algorithm to determine the risk score of each algorithm, and the structured algorithm files of each algorithm are stored in a differentiated hierarchical manner based on the risk scores of the algorithms.

2. The method according to claim 1, characterized in that, The acquisition of the raw data packets generated during the runtime of the target educational software includes: The raw data packets generated during the runtime of the target educational software are obtained by using data tracking.

3. The method according to claim 2, characterized in that, The method of acquiring raw data packets generated during the runtime of the target educational software using data tracking includes: Obtain the pre-generated data acquisition code; The data acquisition code is embedded into the key interactive nodes and / or backend service interfaces of the target educational software; When a predefined trigger event is detected, the data acquisition code captures the raw data packet associated with the trigger event. The trigger event includes at least one of the following: algorithm call event, algorithm execution parameter event, algorithm output event, and user feedback event.

4. The method according to claim 1, characterized in that, The preprocessing of the original data packet to generate algorithm data records includes: Integrity verification is performed on each key field in the original data packet to obtain verified data. The verified data is then converted into a predefined standard data structure to obtain the algorithm data record.

5. The method according to claim 1, characterized in that, The step of extracting a structured algorithm file for at least one algorithm to be tested from the algorithm data record includes: Based on the algorithm identifier in the algorithm data record, the static metadata of the algorithm is obtained by querying. The static metadata includes at least: algorithm type, model architecture, deployment environment, and current active version number. Based on the input parameters and output results in the algorithm data record, the dynamic running characteristics of the algorithm are extracted. The dynamic running characteristics include: input characteristics, output characteristics, and execution characteristics. Based on the algorithm identifier in the algorithm data record, the model attribute information of the algorithm is determined. The model attribute information includes: the algorithm model version number and the associated record of the training dataset used.

6. The method according to claim 1, characterized in that, The risk assessment of the structured algorithm files for each of the algorithms, and the determination of the risk score for each algorithm, includes: Based on the associated records of the training dataset used in the model attribute information, the baseline features during algorithm training are determined; Determine the feature similarity between the input features in the dynamic operation features and the baseline features. If the feature similarity exceeds a preset similarity threshold, then determine the data drift risk score of the algorithm. Determine the output features in the dynamic operation features, and determine the model accuracy score of the algorithm; The latency anomaly score of the algorithm is determined based on the execution characteristics in the dynamic operation characteristics. Based on a preset risk weighting model, the data drift risk score, the model accuracy score, and the latency anomaly score are weighted and summed to obtain the risk score of the algorithm.

7. The method according to claim 1, characterized in that, The risk scoring based on the algorithm, and the differentiated hierarchical storage of the structured algorithm archive of the algorithm, include: If the risk score of the algorithm is greater than or equal to the first threshold, the risk level of the algorithm is determined to be the first risk level, and the structured algorithm file of the algorithm is stored in a high-performance SSD database. If the risk score of the algorithm is less than the first threshold, the risk level of the algorithm is determined to be the second risk level or the third risk level, and the structured algorithm file of the algorithm is stored in the pre-built data lake, wherein the risk of the first risk level is higher than the risk of the second risk level, and the risk of the second risk level is higher than the risk of the third risk level.

8. A data processing device for educational software, characterized in that, The device includes: The acquisition module is used to acquire the raw data packets generated by the target educational software during runtime. The raw data packets include at least: context parameters, which include the algorithm identifier being called, input parameters, and output results. The processing module is used to preprocess the original data packet to generate algorithm data records; The extraction module is used to extract a structured algorithm file of at least one algorithm to be verified from the algorithm data record. The structured algorithm file includes: static attribute information, dynamic running features, and model attribute information. The evaluation module is used to perform risk assessment on the structured algorithm files of each of the algorithms and determine the risk score of each algorithm. The storage module is used to perform differentiated hierarchical storage of the structured algorithm archive based on the risk score of the algorithm.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is in operation, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which is executed by a processor to perform the method as described in any one of claims 1-7.

Images