Model information processing method and electronic device

Abstract

The embodiment of the application discloses a model information processing method and an electronic device, comprising: obtaining metadata of a model from a log after connecting with a plurality of model research and development systems and perceiving addition or version change log of the model; setting a compliance risk assessment aperture in a system related to model deployment, perceiving an event of deploying a certain model to a target application scenario, triggering an evaluation process, obtaining application scenario asset metadata from evaluation information, and creating or updating a mapping relationship between the model and the application scenario; obtaining record asset metadata from record evaluation results included in the evaluation information, and creating or verifying a mapping relationship between the application scenario and the record file; and establishing a ternary relationship composed of the model, the application scenario and the record file, so as to perform model information compliance management based on the ternary relationship. Through the embodiment of the application, the real-time, accuracy and legal effect of the asset association relationship can be ensured, and the data island is eliminated.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to model information processing methods and electronic devices. Background Technology

[0002] With the explosive growth of AIGC (Artificial Intelligence Generated Content) technology, some companies providing AIGC services may experience a surge in the number of AI models, and the lifecycle of these models from training to application may span multiple heterogeneous platforms (e.g., trained on platform A, deployed on platform B, and released as a service through platform C). Simultaneously, domestic and international laws and regulations concerning AI models are rapidly evolving, with increasingly stringent regulatory requirements. For example, deploying AI models to external application scenarios requires registration; some applications using AI algorithms require ethical reviews; and AI-generated content needs to be labeled, and so on. This generates a significant amount of compliance management needs related to AIGC services within enterprises. During compliance management, it is necessary to know where specific AI models are trained, deployed, used in which scenarios, and whether they are registered. However, this data may be scattered across different systems, making manual maintenance of mapping relationships inefficient, error-prone, and unable to reflect compliance status in real time.

[0003] To address the issues inherent in manual methods, compliance checkpoints can be built separately on each AI platform. For example, compliance check logic can be directly embedded in the code of each AI R&D platform (such as training, deployment, and release platforms). When a user performs operations such as uploading or releasing a model, the platform can force a compliance form to pop up, and the user can only continue after completing and passing the verification. However, this only controls the moment of "release" and cannot monitor "silent upgrades" or "configuration changes" after model release (such as prompt adjustments or weight fine-tuning without re-releasing a version). When external regulations change, the hard-coded rules of each platform need to be modified one by one, resulting in long maintenance cycles, extremely high development and maintenance costs, and an inability to meet agile compliance requirements or adapt to the rapid emergence of new platforms. Summary of the Invention

[0004] This application provides a model information processing method and electronic equipment that can ensure the real-time nature, accuracy, and legal validity of asset associations, and eliminate data silos.

[0005] This application provides the following solution: A model information processing method, comprising: After connecting with multiple model development systems and detecting the new model or version change logs, the model's metadata is obtained from the logs according to the preset model metadata definition information. By setting up compliance risk assessment checkpoints in the system related to model deployment, the system can detect events of deploying a model to a target application scenario and trigger a review process. After receiving the review information submitted in the review process, the system can obtain the application scenario asset metadata from the review information based on the pre-defined application scenario asset metadata, and create or update the mapping relationship between the model and the application scenario. Based on the pre-defined metadata of the filed assets, the metadata of the filed assets is obtained from the filing assessment results included in the review information, and a mapping relationship between the application scenario and the filing file is created or verified. Based on the mapping relationship between the model and the application scenario, and the mapping relationship between the application scenario and the filing file, a ternary relationship consisting of the model, the application scenario, and the filing file is established so as to carry out model information compliance management based on the ternary relationship.

[0006] This also includes: By connecting to the model deployment system, we obtain the traffic information generated during the process of calling the model in the application scenario, and use the traffic information to fill in the application scenarios and their mapping relationship with the model that were missed in the model deployment review process.

[0007] This also includes: After triggering the review process based on the perceived event of deploying a model to a target application scenario, it is determined whether the target application scenario can be merged with a historical application scenario that has already been filed. If so, the filing evaluation process for the target application scenario is skipped, and the target application scenario is added to the mapping relationship between the historical application scenario and the filing file.

[0008] This also includes: Based on the aforementioned ternary relationship, a relationship graph is established between the model, application scenarios, and filing files. The relationship graph is visualized and dynamically updated when a node in the relationship graph is updated.

[0009] This also includes: Based on the model information compliance management requirements, it transforms them into executable digital rules and provides a rule engine; The rule engine is used to scan the nodes and relationships in the relationship graph. If a certain ternary relationship matches one of the digital rules, the model, associated application scenario, and filing file in the ternary relationship are marked as objects with compliance risks, and a new round of multi-role collaborative review tasks are triggered to prompt the updating of asset information, supplementation of filing files, and / or adjustment of application scenario configuration.

[0010] This also includes: After the completion of the new round of multi-role collaborative review task, and after updating asset information, supplementing filing files and / or adjusting application scenario configuration, the relationship graph is updated.

[0011] A model information processing device, comprising: The model asset information acquisition unit is used to obtain the model's metadata from the logs after interfacing with multiple model development systems and sensing the addition or version change logs of the model, according to the preset model metadata definition information. The scenario asset information acquisition unit is used to detect the event of deploying a model to a target application scenario by setting up a compliance risk assessment checkpoint in the system related to model deployment, and trigger the review process. After receiving the review information submitted in the review process, it obtains the application scenario asset metadata from the review information according to the preset application scenario asset metadata definition information, and creates or updates the mapping relationship between the model and the application scenario. The filing file asset information acquisition unit is used to acquire filing asset metadata from the filing assessment results included in the review information based on the pre-set filing asset metadata definition information, and to create or verify the mapping relationship between the application scenario and the filing file. The ternary relationship establishment unit is used to establish a ternary relationship consisting of the model, application scenario, and filing file based on the mapping relationship between the model and the application scenario, and the mapping relationship between the application scenario and the filing file, so as to carry out model information compliance management based on the ternary relationship.

[0012] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of any of the preceding methods.

[0013] An electronic device, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of any of the preceding methods.

[0014] A computer program product includes a computer program / computer executable instructions that, when executed by a processor in an electronic device, implement the steps of any of the preceding methods.

[0015] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application's embodiments define three types of assets and, by interfacing with multiple model development systems and detecting model additions or version change logs, obtain metadata related to model assets through these logs. Furthermore, by setting up compliance risk assessment checkpoints in model deployment-related systems, the system detects events related to the deployment of a model to a target application scenario and triggers a review process. Metadata related to scenario assets and filing file assets is obtained from the review information. Additionally, mapping relationships between models and application scenarios, and between application scenarios and filing files, can be created or updated, establishing a ternary relationship consisting of models, application scenarios, and filing files. Compliance management is then based on this ternary relationship. As can be seen, this solution adopts a hybrid mode of "bypass data synchronization + key node checkpoint": metadata related to model assets can be automatically collected via log bypass, and metadata related to application scenario assets and filing file assets can be collected only by setting a unique "compliance risk assessment checkpoint" at key decision points related to model deployment. Furthermore, by leveraging the "review-as-entry" mechanism in asset data perception and updating, the system no longer relies on post-event supplementary entry. Instead, during the essential compliance review process, a three-dimensional relationship of "model-scenario-filing file" is established based on the identification results of legal experts, achieving native synchronization between business facts and compliance data. The completion of the review signifies the establishment of this three-dimensional relationship, ensuring the real-time nature, accuracy, and legal validity of asset associations and eliminating data silos.

[0016] Of course, any product implementing this application does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of the system architecture provided in the embodiments of this application; Figure 2 This is a flowchart of the method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] 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. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0020] In this application embodiment, a dynamic compliance management system for model information can be provided to compliance managers and other personnel within the enterprise that provides model services. In this system, three types of assets and their preset logical association rules can be defined first, and modules for managing the three types of assets respectively can provide "containers" and "molds" for subsequent data inflow and relationship instantiation.

[0021] These three types of assets can include model assets, application scenario assets, and filing archive assets. Correspondingly, the corresponding management modules can include: Model asset management module: It can define the model metadata structure (such as training platform, number of parameters, fine-tuning method, dataset source, etc.) and supports version lifecycle management (draft / release / decommissioning). Application Scenario Asset Management Module: Defines application scenario metadata, which can include multiple dimensions, such as service object, carrier type, interaction method, whether it is charged, etc., and supports scenario registration and status tracking; The Filing File Asset Management Module defines the metadata of the filing files, mainly various legal elements such as filing number, algorithm type, subject, and public notice link, and supports the transfer of filing status (filed / suspended / cancelled).

[0022] In addition to defining the metadata for the three types of assets, the mapping constraint logic for the three types of assets can also be pre-defined at the system level: Model Application scenario: Supports many-to-many relationships (one model serves multiple scenarios, and one scenario calls multiple models). Application scenarios Filing files: Supports one-to-many or many-to-one relationships (one scenario corresponds to one main filing, or one filing covers multiple similar application scenarios). The above stage only establishes the data structure and logical constraints, and has not yet generated specific business instance data. After defining the asset metadata and logical association rules, the specific model information compliance management process can begin. In this management process, such as... Figure 1As shown, the first step is to perceive and update resource data. This capability is the core of the data-driven approach in this application's embodiments. By connecting with the production data of multiple model development systems (including model registration systems, model training systems, model deployment systems, model release systems, etc.), the metadata of the model is perceived. At key nodes, the connection forms a "compliance checkpoint" and triggers a mandatory review process. By utilizing the expert review results during the review process, the addition, iteration, and establishment of relationships of asset information are proactively perceived and promoted.

[0023] Specifically, the first step is to be aware of model asset data. This can be achieved by integrating with multiple model development platforms (training, deployment, release, etc.) to automatically capture logs of new model additions and version changes. These additions or changes act as "triggers," automatically forming model assets and synchronizing model metadata to the corresponding fields within the model assets, ensuring the comprehensiveness, real-time nature, and accuracy of the model library.

[0024] The perception and updating of application scenarios can be driven by reviews. Specifically, a checkpoint mechanism can be adopted: at key points such as when a model is deployed to the production environment or service parameters are changed, a "compliance risk assessment checkpoint" can be set up. When a business party attempts to deploy a model to the production environment or change service parameters, it must first pass through the aforementioned "compliance risk assessment checkpoint." In the review process, a "review-as-entry" approach is adopted: first, legal / compliance experts (who can conduct multi-party reviews, including security reviews, legal reviews, etc.) and other personnel review the materials submitted by the business party, including filing and ethical reviews. In addition, it can also identify whether the business behavior constitutes a "new application scenario" or a "significant change to an existing scenario." If it is identified as a new application scenario, a new application scenario asset record can be created directly in the system based on the information submitted in the review process. Specifically, the metadata of the specific application scenario can be obtained from the submitted information based on the metadata definition information of the application scenario asset, and a corresponding application scenario asset record can be created in the application scenario asset information database. If it is identified as an application scenario change, it can trigger a version iteration update of the original application scenario asset. In addition, since the process of perceiving application scenario information also involves associated models, a mapping relationship between specific models and application scenarios can be created simultaneously.

[0025] By setting up review checkpoints during model deployment, the application scenarios deployed online can be fully and accurately recorded, and change records of related application scenario information can be archived, reducing the likelihood of missed reports. Of course, in practical applications, to further prevent missed reports, it is also possible to interface with the specific model deployment system to obtain traffic information generated during the application scenario's call to the model. This traffic information can then be used to complete the review process for any application scenarios missed and their mapping relationships with the model.

[0026] In addition, filing assessment is one of the modules that needs to be completed in the compliance review process. During the filing assessment, legal experts can determine whether the current application scenario touches on regulatory boundaries (e.g., prohibited behaviors) and whether new filings or updates to existing filings are needed, based on model attributes (e.g., generated composite classes) and application scenario characteristics (e.g., publicly available services, internal applications). If new filings are needed, the review process can guide users to initiate a filing application. After the filing is completed, the system can automatically establish a mapping relationship between the "application scenario" and the newly generated "filing file". If an existing filing is reused, the review process needs to confirm whether the current scenario is within the scope of the original filing, thereby verifying the existing mapping relationship. In this way, "identifying needs during the review, completing filing during the review, and establishing relationships during the review" can be achieved, ensuring the authenticity and legal validity of the mapping relationship between the application scenario and the filing file. The same model may be deployed in multiple similar application scenarios; in this case, these application scenarios can share the same filing. Therefore, when it is detected that a model has been deployed to a certain application scenario, the application scenario can be judged to determine whether the specific model has been filed for existing similar application scenarios. If so, the historical review content can be brought in to update the mapping relationship between the application scenario and the filing file; otherwise, the review can be carried out normally.

[0027] Following the review of the model deployment process, the dispersed three types of asset data have been assigned genuine business-related attributes. This allows for the establishment of a ternary relationship consisting of the model, application scenarios, and filing documents. Subsequent compliance management of model information can be based on this ternary relationship. Because it can detect model additions or version changes, as well as deployment events in specific application scenarios, this ternary relationship can be dynamically updated.

[0028] The specific implementation schemes provided in the embodiments of this application will be described in detail below.

[0029] First, this application provides a model information processing method, which can be applied to the aforementioned model information dynamic compliance management system. (See [link to relevant documentation]). Figure 2 The method may include: S201: After connecting with multiple model development systems and sensing the logs of new or version changes of models, obtain the model's metadata from the logs according to the preset model metadata definition information.

[0030] Since a single enterprise may have multiple different model development systems (or "platforms"), including the possibility that the same model may be trained, deployed, and released on different systems, the model information dynamic compliance management system provided in this application embodiment can interface with these different model development systems respectively. Through these interfaces, the model information dynamic compliance management system can detect model additions or version change logs. Then, according to pre-defined model metadata, it can retrieve model metadata from the logs and create or update corresponding model asset records in the model asset information library. Specifically, it can retrieve data on fields such as the model's training platform, parameter count, fine-tuning method, and dataset source, and then synchronize this model metadata to the corresponding fields in the model assets to ensure the comprehensiveness and accuracy of the model library. The task of retrieving model addition or version change logs can be performed in real-time, or it can be summarized on a T+1 basis (retrieved the day after the specific model addition or change event occurs) and then provided to the model information dynamic compliance management system via an offline table, etc., depending on the urgency of the risk.

[0031] It should be noted that although the same model may be trained, deployed, and released in different model development systems, meaning that the data related to model training, deployment, and release will be scattered across multiple different model development systems, the model ID and other identifiers of the same model usually remain unchanged after registration. Therefore, the data of the same model can be associated through unique identifiers such as the model ID. In other words, the data scattered across multiple different model development systems can be aggregated through identifiers such as the model ID to obtain the metadata of the same model in multiple different fields.

[0032] S202: By setting up compliance risk assessment checkpoints in the system related to model deployment, the system detects the event of deploying a model to a target application scenario and triggers the review process. After receiving the review information submitted in the review process, the system obtains the application scenario asset metadata from the review information according to the pre-set application scenario asset metadata definition information, creates or updates the corresponding application scenario asset record in the application scenario asset information database, and creates or updates the mapping relationship between the model and the application scenario.

[0033] In addition to interfacing with various model development systems, compliance risk assessment checkpoints can be set up in model deployment-related systems to detect events indicating the deployment of a model to a target application scenario and trigger a review process. In other words, the model deployment phase involves deploying the model to a specific application scenario, which could be internal or external, and may also involve a filing process. Therefore, corresponding risk assessment checkpoints can be set up at this deployment stage to drive the review process. Specifically, after detecting an event indicating model deployment to a specific application scenario, the business team can be prompted to submit relevant review materials for that application scenario. A review page can be provided to the business team, allowing them to fill out and submit the relevant review materials. Once completed, the review is triggered. The review process can include multiple review nodes, such as security-related reviews, legal-related reviews, etc. Security-related reviews can be further subdivided into various roles, including application security, content security, and basic security. Different review tasks can be distributed to different legal / compliance experts, who will then review the materials submitted by the business team. During the review process, it can be determined whether the application scenario is a new scenario. If so, the data for the required fields of the scenario metadata can be extracted from the review information, and a corresponding scenario record can be created in the scenario asset information database. If it is not a new scenario, but involves scenario changes, the metadata of the existing scenario record can be updated.

[0034] In addition to acquiring scene metadata and creating / updating scene asset records, it is also possible to create / update the mapping relationship between models and application scenes. For example, if a review process is triggered during the deployment of model A to scene 1, then while creating / updating the scene asset record of scene 1, a mapping relationship between model A and scene 1 can also be created to indicate that model A has been deployed to scene 1.

[0035] Furthermore, the "checkpoints" set up in the model deployment stage in this embodiment are not mandatory. That is, after detecting a model deployment event, the business party can be prompted to submit materials for review. However, there may be situations where the business party fails to submit materials, potentially leading to omissions of certain scenario assets and the aforementioned mapping relationships between models and assets. To address this, the model deployment-related system typically builds a model service during model deployment. This service can monitor the traffic generated during the process of specific application scenarios calling the model. It can also be used for authentication management, such as determining which application scenarios are allowed to call a specific model and the number of times each application scenario calls the model. This frequency information may be related to cost accounting, etc. In short, the model deployment-related system contains specific traffic monitoring services. Through these services, it is possible to monitor which application scenarios are calling the model. Therefore, this embodiment can obtain this traffic information from the model deployment system and then use this traffic information to complete the missing application scenarios and their mapping relationships with the model in the model deployment review process.

[0036] S203: Based on the pre-set filing asset metadata definition information, obtain the filing asset metadata from the filing assessment results included in the review information, create or update the corresponding filing asset record in the filing asset information database, and create or verify the mapping relationship between the application scenario and the filing file.

[0037] The review process involves the filing of application scenarios. In this embodiment, the filing file is also a type of asset. Therefore, based on the pre-defined filing asset metadata, the filing asset metadata can be obtained from the filing assessment results included in the review information. Corresponding filing asset records can also be created or updated in the filing asset information database. Furthermore, a mapping relationship between application scenarios and filing files can be created or verified. Specifically, if a new filing is required, the review process can guide the user to initiate a filing application. After the filing is completed, the system automatically establishes a mapping relationship between the "application scenario" and the newly generated "filing file".

[0038] Furthermore, when the same model is deployed to multiple different application scenarios, if these different application scenarios belong to the same category, they can share the same filing file. Therefore, in practical applications, after triggering the review process based on the perceived event of deploying a model to a target application scenario, it can be determined whether the target application scenario can be merged with a historically filed application scenario. If so, the filing evaluation process for the current target application scenario can be skipped, and the target application scenario can be added to the mapping relationship between the historical application scenarios and the filing file. For example, suppose that application scenario 1 has been registered, corresponding to registration file X; and then the same model needs to be deployed to application scenario 2, we can first determine whether there is a scenario of the same type as application scenario 2 among the already registered scenarios. For example, suppose it is determined that application scenario 1 is the same type of scenario as application scenario 2. At this time, application scenario 2 can be merged with application scenario 1 for registration. That is, it is not necessary to re-register application scenario 2, but simply add application scenario 2 to the mapping relationship with registration file X: originally there was a mapping relationship between application scenario 1 and registration file X, now it can be updated to have mapping relationships between application scenario 1 and application scenario 2 and registration file X.

[0039] S204: Based on the mapping relationship between the model and the application scenario, and the mapping relationship between the application scenario and the filing file, establish a ternary relationship consisting of the model, the application scenario, and the filing file, so as to carry out model information compliance management based on the ternary relationship.

[0040] Through the aforementioned steps, metadata for three types of assets can be obtained, and mapping relationships between models and application scenarios, as well as between application scenarios and filing files, can be established. Furthermore, a ternary relationship consisting of models, application scenarios, and filing files can be established, enabling compliance management of model information based on this ternary relationship. Since the creation, modification, and deployment of models to application scenarios may all occur dynamically, and the compliance management system provided in this embodiment can detect these dynamic events, this ternary relationship can also be dynamically changing.

[0041] Optionally, a relationship graph for the three asset classes can be automatically constructed based on the aforementioned ternary relationship, enabling the instantiation of dynamic mapping relationships. Specifically, the "model – application scenario – filing file" ternary relationship confirmed in the review conclusion can be written into the graph database. For example: [Model V2.0] --(serves)-->[Scenario A_E-commerce Customer Service] --(belongs to)-->[Filing Number *****]. After constructing the relationship graph, dynamic visualization can be performed. That is, not only can a static relationship list be displayed through the specific relationship graph, but the dependency network between the three asset classes can also be presented in real time. Any change to any node (such as model upgrade, filing cancellation, etc.) can be highlighted in the graph to show its impact scope immediately. For example, which application scenarios are affected by a model upgrade, which application scenarios are affected by filing cancellation, etc.

[0042] Furthermore, dynamic and continuous assessments of compliance risks based on regulatory requirements can better address the issue that "one-time reviews cannot cope with continuous changes." During the continuous assessment process, the system can transform the latest regulatory requirements into an executable digital rule engine to automatically scan and issue warnings on the existing dynamic risk map, triggering a new round of assessment cycles. Specifically, external laws and regulations can be broken down into specific judgment rules, for example: Rule A: IF Model parameter count > a certain threshold AND Service object = “Overseas” THEN Trigger “A certain risk review”. Rule B: IF Algorithm type = “Deep Synthesis” AND Filing status = “Unfiled” AND Launch time > 3 months THEN trigger “Filing missing warning”. Rule C: IF model training data contains “sensitive personal information” AND technology ethics review expires THEN triggers “ethics re-review”.

[0043] Based on the aforementioned executable judgment rules, the rule engine can periodically or in real-time traverse all nodes and relationships in the compliance relationship graph. If a ternary relationship matches a rule (e.g., a model is marked as "External ToC" due to business adjustments, triggering rule B), the system can automatically add risk markers such as "high risk" to the model in that ternary relationship and its associated scenarios and filing files, and automatically initiate a new round of multi-role collaborative review tasks. The newly triggered review process can prompt business parties to update asset information, supplement filings, or adjust scenario configurations. Then, the graph can be updated again based on the review results, forming an automated closed loop of "perception → review → graph building → rule scanning → re-perception," ensuring that the enterprise's model information compliance status is always synchronized with the latest regulatory requirements.

[0044] In summary, this application's embodiments define three types of assets and, by interfacing with multiple model development systems and detecting model additions or version change logs, obtain metadata related to model assets through these logs. Furthermore, by setting up compliance risk assessment checkpoints in model deployment-related systems, the system detects events related to the deployment of a model to a target application scenario and triggers a review process. Metadata related to scenario assets and filing file assets is obtained from the review information. Moreover, the system can create or update mapping relationships between models and application scenarios, and between application scenarios and filing files, thereby establishing a ternary relationship consisting of models, application scenarios, and filing files. Compliance management is then based on this ternary relationship. It is evident that this solution adopts a hybrid mode of "bypass data synchronization + key node checkpoint": metadata related to model assets can be automatically collected via log bypass, and metadata related to application scenario assets and filing file assets can be collected only by setting a unique "compliance risk assessment checkpoint" at key decision points related to model deployment. Furthermore, by leveraging the "review-as-entry" mechanism in asset data perception and updating, the system no longer relies on post-event supplementary entry. Instead, during the essential compliance review process, a three-dimensional relationship of "model-scenario-filing file" is established based on the identification results of legal experts, achieving native synchronization between business facts and compliance data. The completion of the review signifies the establishment of this three-dimensional relationship, ensuring the real-time nature, accuracy, and legal validity of asset associations and eliminating data silos.

[0045] In the aforementioned more preferred implementation, the embodiments of this application further construct a four-layer closed-loop system of "asset management - checkpoint perception - graph construction - rule-driven", fundamentally overcoming the shortcomings of traditional "embedded checkpoint" or "manual static management" modes: 1. Overcome the drawbacks of "data silos and relationship fragmentation": Traditional pain points: Models, scenarios, and filing information are scattered and rely on manual maintenance through spreadsheets, which is outdated and prone to errors. The solution provided in this application is to utilize the "review-entry" mechanism in asset data perception and updating, so as to no longer rely on post-event supplementary entry, but instead, in the necessary business process of compliance review, legal experts identify and confirm the three-element relationship of "model-scenario-filing". Technical Results: Native synchronization of business facts and compliance data was achieved. The completion of the review signifies the establishment of the data graph relationships, ensuring the real-time nature, accuracy, and legal validity of asset associations, and completely eliminating data silos. 2. Overcome the drawbacks of "high docking costs and strong invasiveness": Traditional pain points: Requires modification of all AI platform code, making promotion difficult and maintenance arduous. The solution provided in this application is a hybrid approach of "bypass data synchronization + key node checkpoint". Model data is automatically collected via log bypass, and a unique "compliance risk assessment checkpoint" is set only at key decision points related to model deployment. Technical benefits: It reduces the complexity of system integration, and enables the management of all assets without requiring deep invasive modifications to the existing model development platform, significantly reducing implementation costs and promotional obstacles. 3. Overcome the shortcomings of "blind spots in full lifecycle monitoring": Traditional pain points: Compliance assessments rely on proactive reporting, which cannot ensure coverage of management actions or identify subsequent risks arising from model fine-tuning, scenario changes, or regulatory updates. The solution provided in this application is as follows: introduce asset data perception and updating and dynamic continuous assessment of compliance risks based on regulatory requirements to form a strong control over production asset data, and transform external laws and regulations into a digital rule engine that can continuously and automatically scan the constructed dynamic knowledge graph. Technical effect: It realizes the transformation from "passive response" to "proactive early warning". Once the model attributes change (such as a surge in the number of parameters) or regulations are updated (such as the addition of certain restrictions), the system can immediately hit the rules and automatically trigger a new round of review, forming an automated closed loop of "perception -> review -> mapping -> scanning -> re-perception" to ensure no regulatory blind spots. 4. Overcome the drawback of "slow response to compliance strategies": Traditional pain points: Regulatory changes require manual notification and modification of rules on each platform, which takes a long time. The solution provided in this application is to achieve centralized configuration and digital transformation of regulatory rules. Technical benefits: Enables agile iteration of compliance strategies. External regulatory changes only require a single configuration update in the central rules engine to immediately apply to the scanning and assessment of all assets, thus shortening compliance response time.

[0046] It should be noted that the embodiments of this application may involve the use of user data. In practical applications, user-specific personal data may be used in the scheme described herein within the scope permitted by applicable laws and regulations, provided that it complies with the applicable laws and regulations of the country (e.g., with the user's explicit consent, with the user being properly notified, etc.).

[0047] Corresponding to the foregoing method embodiments, this application also provides a model information processing device, see below. Figure 3 The device may include: The model asset information acquisition unit 301 is used to obtain the model's metadata from the logs after interfacing with multiple model development systems and sensing the model's new additions or version change logs, according to the preset model metadata definition information. The scenario asset information acquisition unit 302 is used to detect the event of deploying a model to a target application scenario by setting up a compliance risk assessment checkpoint in the system related to model deployment and triggering a review process. After receiving the review information submitted in the review process, it obtains the application scenario asset metadata from the review information according to the preset application scenario asset metadata definition information and creates or updates the mapping relationship between the model and the application scenario. The filing file asset information acquisition unit 303 is used to acquire filing asset metadata from the filing assessment results included in the review information according to the pre-set filing asset metadata definition information, and to create or verify the mapping relationship between the application scenario and the filing file. The ternary relationship establishment unit 304 is used to establish a ternary relationship consisting of the model, the application scenario, and the filing file based on the mapping relationship between the model and the application scenario, and the mapping relationship between the application scenario and the filing file, so as to carry out model information compliance management based on the ternary relationship.

[0048] In a specific implementation, the device may further include: The information completion unit is used to obtain traffic information generated during the process of calling the model by the application scenario through the model deployment system, and to complete the application scenarios and their mapping relationship with the model that were missed in the model deployment review process through the traffic information.

[0049] Additionally, it may include: The merge filing judgment unit is used to determine whether the target application scenario can be merged with the historical application scenario that has been filed after the review process is triggered by the perceived event of deploying a certain model to the target application scenario. If so, the filing evaluation process for the target application scenario is skipped, and the target application scenario is added to the mapping relationship between the historical application scenario and the filing file.

[0050] The relationship graph building unit is used to build a relationship graph between the model, application scenarios, and filing files based on the ternary relationship. The visualization unit is used to visualize the relationship graph and dynamically update the visualization results when the nodes in the relationship graph are updated.

[0051] Additionally, it may include: The rules engine provides units for transforming compliance management requirements based on model information into executable digital rules, and provides the rules engine; The rule scanning unit is used to scan the nodes and relationships in the relationship graph using the rule engine. If a certain ternary relationship matches one of the digital rules, the model, associated application scenario, and filing file in the ternary relationship are marked as objects with compliance risks, and a new round of multi-role collaborative review tasks are triggered to prompt the updating of asset information, supplementation of filing files, and / or adjustment of application scenario configuration.

[0052] Additionally, the device may also include: The graph update unit is used to update the relationship graph after the completion of the new round of multi-role collaborative review task and after updating asset information, supplementing filing files and / or adjusting application scenario configuration.

[0053] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0054] And an electronic device, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any of the foregoing method embodiments.

[0055] A computer program product includes a computer program / computer executable instructions that, when executed by a processor in an electronic device, implement the steps of the method described in the foregoing method embodiments.

[0056] in, Figure 4 An exemplary architecture of an electronic device is shown, which may include a processor 410, a video display adapter 411, a disk drive 412, an input / output interface 413, a network interface 414, and a memory 420. The processor 410, video display adapter 411, disk drive 412, input / output interface 413, network interface 414, and memory 420 can communicate with each other via a communication bus 430.

[0057] The processor 410 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solution provided in this application.

[0058] The memory 420 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 420 can store the operating system 421 for controlling the operation of the electronic device 400, and the basic input / output system (BIOS) for controlling the low-level operations of the electronic device 400. Additionally, it can store a web browser 423, a data storage management system 424, and a model information processing system 425, etc. The aforementioned model information processing system 425 can be the application program that specifically implements the aforementioned steps in this embodiment. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 420 and is called and executed by the processor 410.

[0059] Input / output interface 413 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0060] Network interface 414 is used to connect a communication module (not shown in the figure) to enable communication and interaction between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0061] Bus 430 includes a pathway for transmitting information between various components of the device, such as processor 410, video display adapter 411, disk drive 412, input / output interface 413, network interface 414, and memory 420.

[0062] It should be noted that although the above-described device only shows the processor 410, video display adapter 411, disk drive 412, input / output interface 413, network interface 414, memory 420, bus 430, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0063] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0064] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0065] The model information processing method and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and its core ideas. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A model information processing method, characterized in that, include: After connecting with multiple model development systems and detecting the new model or version change logs, the model's metadata is obtained from the logs according to the preset model metadata definition information. By setting up compliance risk assessment checkpoints in the system related to model deployment, the system can detect events of deploying a model to a target application scenario and trigger a review process. After receiving the review information submitted in the review process, the system can obtain the application scenario asset metadata from the review information based on the pre-defined application scenario asset metadata, and create or update the mapping relationship between the model and the application scenario. Based on the pre-defined metadata of the filed assets, the metadata of the filed assets is obtained from the filing assessment results included in the review information, and a mapping relationship between the application scenario and the filing file is created or verified. Based on the mapping relationship between the model and the application scenario, and the mapping relationship between the application scenario and the filing file, a ternary relationship consisting of the model, the application scenario, and the filing file is established so as to carry out model information compliance management based on the ternary relationship.

2. The method according to claim 1, characterized in that, Also includes: By connecting to the model deployment system, we obtain the traffic information generated during the process of calling the model in the application scenario, and use the traffic information to fill in the application scenarios and their mapping relationship with the model that were missed in the model deployment review process.

3. The method according to claim 1, characterized in that, Also includes: After triggering the review process based on the perceived event of deploying a model to a target application scenario, it is determined whether the target application scenario can be merged with a historical application scenario that has already been filed. If so, the filing evaluation process for the target application scenario is skipped, and the target application scenario is added to the mapping relationship between the historical application scenario and the filing file.

4. The method according to claim 1, characterized in that, Also includes: Based on the aforementioned ternary relationship, a relationship graph is established between the model, application scenarios, and filing files. The relationship graph is visualized and dynamically updated when a node in the relationship graph is updated.

5. The method according to claim 4, characterized in that, Also includes: Based on the model information compliance management requirements, it transforms them into executable digital rules and provides a rule engine; The rule engine is used to scan the nodes and relationships in the relationship graph. If a certain ternary relationship matches one of the digital rules, the model, associated application scenario, and filing file in the ternary relationship are marked as objects with compliance risks, and a new round of multi-role collaborative review tasks are triggered to prompt the updating of asset information, supplementation of filing files, and / or adjustment of application scenario configuration.

6. The method according to claim 5, characterized in that, Also includes: After the completion of the new round of multi-role collaborative review task, and after updating asset information, supplementing filing files and / or adjusting application scenario configuration, the relationship graph is updated.

7. A model information processing device, characterized in that, include: The model asset information acquisition unit is used to obtain the model's metadata from the logs after interfacing with multiple model development systems and sensing the addition or version change logs of the model, according to the preset model metadata definition information. The scenario asset information acquisition unit is used to detect the event of deploying a model to a target application scenario by setting up a compliance risk assessment checkpoint in the system related to model deployment, and trigger the review process. After receiving the review information submitted in the review process, it obtains the application scenario asset metadata from the review information according to the preset application scenario asset metadata definition information, and creates or updates the mapping relationship between the model and the application scenario. The filing file asset information acquisition unit is used to acquire filing asset metadata from the filing assessment results included in the review information based on the pre-set filing asset metadata definition information, and to create or verify the mapping relationship between the application scenario and the filing file. The ternary relationship establishment unit is used to establish a ternary relationship consisting of the model, application scenario, and filing file based on the mapping relationship between the model and the application scenario, and the mapping relationship between the application scenario and the filing file, so as to carry out model information compliance management based on the ternary relationship.

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

9. An electronic device, characterized in that, include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program / computer-executable instructions, characterized in that, When the computer program / computer executable instructions are executed by a processor in an electronic device, they implement the steps of the method according to any one of claims 1 to 6.

Images