A large model-based data interface automatic generation method and system

Abstract

The application discloses a kind of data interface automatic generation method and system based on large model, it is related to data interface management and API service automatic generation technical field, including the following steps: S1, gather external interface data and platform management data, form data set;S2, call GPT large model analysis data set, form configuration draft;S3, correct cross-supplier configuration difference, form uniform interface configuration object;S4, arrange for combined API configuration item dependency matrix;S5, dependency matrix access improves xDeepFM model, is compressed interaction network CIN generation configuration feature map and compresses configuration outer product tensor, and output service definition result;S6, execute sample test and release check, form publishable service;S7, access running management link and reuse when supplier interface changes, form executable service.The application improves data interface automatic generation, combined API configuration consistency and change reuse capability.

Description

Technical Field

[0001] This invention relates to the field of data interface governance and automatic API service generation technology, and in particular to a method and system for automatic generation of data interfaces based on a large model. Background Technology

[0002] Existing methods for managing external data interfaces typically rely on manual reading of vendor interface documentation, followed by developers manually configuring service definitions, request parameters, return fields, code value conversions, test cases, and release status. While this approach can achieve basic integration for a single vendor interface, the configuration process depends on human experience and is susceptible to issues such as inconsistent interface documentation formats, incomplete field descriptions, and differences in sample messages.

[0003] As the number of vendors connected to external data service platforms increases, the same type of data service often needs to be published uniformly through a combined API. There are inconsistencies between different vendors in request field naming, return structure hierarchy, business codes, response codes, and billing methods. Existing methods mostly use a decentralized configuration approach to handle mapping, transcoding, routing, testing, and deployment, which makes it difficult to ensure that each configuration item is continuously supported in the context of the combined API.

[0004] Furthermore, existing interface configuration tools typically only focus on interface definition generation or test results, lacking unified processing for service bus, monitoring and statistics, billing and accounting, lineage analysis, and vendor change reuse. When vendor interface content changes, manual investigation of the impact and synchronous adjustment of configuration are required, resulting in low efficiency of automatic interface generation and insufficient consistency in deployment and operation.

[0005] Therefore, how to provide a method and system for automatically generating data interfaces based on large models is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] One objective of this invention is to propose an automatic data interface generation method and system based on a large model. This invention employs a method combining GPT large model parsing and an improved xDeepFM model. It generates a draft data interface configuration through data interface dataset parsing and corrects for cross-vendor interface configuration differences, forming a unified data interface service configuration object. Based on this, the unified data interface service configuration object is organized into a combined API configuration item dependency matrix. The configuration feature map of the compressed interaction network (CIN) and tensor decomposition convolutional kernels in the improved xDeepFM model are used to generate the data interface service definition results. This enables interface sample testing, release flow verification, service bus operation governance, and vendor change reuse. It has advantages such as high interface generation efficiency, strong consistency across multiple vendor configurations, stable release and operation integration, and strong vendor change reuse capabilities.

[0007] According to an embodiment of the present invention, an automatic data interface generation method based on a large model includes the following steps: S1. Collect external data interface information and platform service governance information, clean up interface description noise and merge them into a data interface information set; S2. Call the GPT large model parsing data interface dataset, decompose the interface description content into data interface semantic units, and assemble them into a data interface configuration draft; S3. Perform cross-supplier interface configuration difference correction on the draft data interface configuration, rewrite the supplier-side configuration into the platform standard service definition, and form a unified data interface service configuration object. S4. Organize the unified data interface service configuration object into a composite API configuration item dependency matrix in the context of composite API runtime, and write the interface configuration acceptance parameters into the matrix positions. S5. Combined API configuration item dependency matrix access improves the xDeepFM model. The compressed interaction network CIN rewrites the ordinary feature domain channel feature map into a configuration feature map with the combined API configuration domain as the main index and linked with the supplier domain and the runtime domain. Tensor decomposition convolution kernel reads the index position of the configuration feature map and compresses the configuration outer product tensor, outputting the data interface service definition result. S6. Perform interface sample testing and release flow verification on the data interface service definition results to form a publishable data interface service; S7. The data interface service access interface operation and governance link can be published. The interface operation and governance link takes over the service operation status and reuses the data interface service definition results when the supplier interface changes, forming an operable data interface service.

[0008] Optionally, S1 includes reading supplier access information and platform service governance information, organizing interface descriptions, call examples, code value descriptions, billing descriptions and platform-side configuration information according to external data service capabilities, deleting page display tags, blank placeholder content and duplicate description content, writing source tags and stage tags, and forming a data interface data set.

[0009] Optionally, S2 specifically includes: S21, GPT large model reads data interface data set, and classifies parsable text into the same parsing task according to the external data service capabilities; S22. Within the parsing task, identify the interface description segment, the call sample segment, and the platform configuration segment, extract the interface call content, the sample message content, and the service governance content, and retain the source tag and the stage tag; S23. Establish semantic correspondences for the extracted content according to the same external data service capabilities; The S24 and GPT large models assemble semantic correspondences into a data interface configuration draft, and retain supplier sources and platform stage sources in the data interface configuration draft.

[0010] Optionally, S3 specifically includes: S31. Read the supplier source and platform stage source in the draft data interface configuration, and establish a cross-supplier configuration correction group according to the same external data service capability; S32. Perform platform-level correction on the interface configuration and service governance configuration in the cross-vendor configuration correction group, and rewrite the vendor-side configuration into platform service definition configuration content and platform-accepted configuration content. S33. Merge the platform service definition configuration content and the platform undertaking configuration content according to the same external data service capability, and retain the supplier source to form a unified data interface service configuration object.

[0011] Optionally, S4 specifically includes: S41. Read the unified data interface service configuration object and verify the platform definition content, supplier adaptation content and runtime acceptance content according to the combined API runtime context. S42. Write the platform definition content into the row side of the combined API configuration item dependency matrix, and write the supplier adaptation content and runtime acceptance content into the column side of the combined API configuration item dependency matrix. S43. At the intersection of the row and column sides, verify the configuration acceptance content under the same external data service capability. If the position is hit, write the interface configuration acceptance parameters. If the position is not hit, leave it as an empty matrix position. S44. Attach the corresponding source content to the empty matrix positions to form a combined API configuration item dependency matrix.

[0012] Optionally, the improved xDeepFM model includes an input embedding layer, a linear part, a compressed interaction network (CIN), a deep neural network part, and an output layer. The compressed interaction network (CIN) includes hidden layer feature maps, outer product tensors, convolutional kernels, and pooling outputs. The hidden layer feature maps are set to be configured with a combination of API configuration domain as the main index and linked with the configuration feature maps of the supplier domain and the runtime domain. The convolutional kernels are composed of configuration domain kernels, supplier kernels, and runtime kernels, forming tensor decomposition convolutional kernels.

[0013] Optionally, S5 specifically includes: S51. The input embedding layer reads the combined API configuration item dependency matrix, generates an embedding vector corresponding to the configuration domain, supplier and runtime phase according to the matrix position, and reads the interface configuration parameters in the linear part to form the basic configuration contribution. S52. The Compressed Interactive Network (CIN) reads the embedded vector, replaces the ordinary feature domain channels of the hidden layer feature map with the combined API configuration domain as the main index and links the supplier domain and the runtime domain, and writes the interface configuration acceptance parameters into the index position corresponding to the matrix position in the configuration feature map. S53. Use configuration feature maps instead of ordinary feature maps to participate in the construction of outer product tensors. Supplier differences and runtime phases under the same combined API configuration domain are jointly entered into the configuration outer product tensor. Missed index positions are retained as empty matrix positions along the original matrix positions. S54. The convolutional kernel is split into configuration domain kernel, supplier kernel and runtime kernel. The configuration domain kernel limits the main index range of the configuration outer product tensor, the supplier kernel limits the range of supplier differences, and the runtime kernel limits the runtime acceptance range. The three types of convolutional kernels together form the tensor decomposition convolutional kernel. S55. Tensor decomposition convolution kernels read the tensor positions in the configuration outer product tensor that are hit by all three types of convolution kernels and perform convolution compression. The tensor positions that are not hit are written back as empty matrix positions to form an updated configuration feature map. S56. The Compressed Interaction Network (CIN) performs pooling on the updated configuration feature map and forms a pooled output. The deep neural network part reads the embedding vector corresponding to the position of the missing matrix to form an implicit configuration association output. The output layer merges the basic configuration contribution, the pooled output, and the implicit configuration association output to form the data interface service definition result.

[0014] Optionally, S6 includes reading the data interface service definition result, organizing the interface sample content and the release status content into an interface release verification task, calling the platform test channel to execute successful example tests and failed example tests, generating test results, filling the test results back into the data interface service definition result, verifying the consistency between the test results and the interface configuration acceptance parameters associated with the data interface service definition result, and determining the release candidate content corresponding to the release status and test results as a releaseable data interface service.

[0015] Optionally, S7 specifically includes: S71. Read the publishable data interface service and register the service definition content, publishing status and combined API routing content to the interface operation governance link; S72. The interface operation governance link performs service bus access verification. After the verification is passed, the interface call is opened and the service operation details are recorded. S73. Summarize service operation details and associate monitoring statistics, billing and accounting results and lineage analysis results with the same publishable data interface service to form the service operation status; S74. When the supplier interface changes, read the supplier's changed content and compare it with the interface configuration acceptance parameters associated with the data interface service definition result to locate the configuration acceptance parameters that need to be adjusted synchronously. S75. Retain the configuration acceptance parameters that were not hit, update the configuration acceptance parameters that were hit according to the supplier's changes, and write the updated configuration acceptance parameters back to the data interface service definition result to form a runnable data interface service.

[0016] According to an embodiment of the present invention, an automatic data interface generation system based on a large model includes the following modules: The data collection module is used to organize external data interface data and platform service governance data, remove interfering content from the interface descriptions, and form a data interface data set. The semantic parsing module is used to call the GPT large model parsing data interface dataset and convert the interface description content into a data interface configuration draft. The difference correction module is used to correct cross-vendor configuration differences in the draft data interface configuration and convert the vendor-side configuration into the platform standard service definition, forming a unified data interface service configuration object. The matrix organization module is used to organize the unified data interface service configuration objects in the context of combined API operation, and organize the configuration content into a combined API configuration item dependency matrix. The model generation module is used to input the combined API configuration item dependency matrix into the improved xDeepFM model, generate configuration feature maps by the compressed interaction network CIN and compress the configuration outer product tensor, and output the data interface service definition result. The test and release module is used to perform interface sample tests and release flow verification on the data interface service definition results to form a publishable data interface service. The runtime governance module is used to connect publishable data interface services to the interface runtime governance link and reuse the data interface service definition results when the supplier interface changes, forming a runnable data interface service.

[0017] The beneficial effects of this invention are: This invention combines GPT large-scale model parsing with an improved xDeepFM model to automatically generate data interface service definitions from external data interface data. The GPT large-scale model performs semantic parsing on vendor access data and platform service governance data, generating draft data interface configurations from interface descriptions, call examples, and platform configurations. This reduces the workload of manually reading interface documents and manually configuring service definitions, alleviating the low configuration efficiency caused by inconsistent interface document formats, incomplete field descriptions, and differences in sample messages.

[0018] Furthermore, this invention addresses multi-vendor similar service access scenarios by performing cross-vendor interface configuration difference correction on the draft data interface configuration and organizing it into a composite API configuration item dependency matrix. By setting the configuration feature map with the composite API configuration domain as the main index and linking the vendor domain and runtime domain in the compressed interactive network (CIN) of the improved xDeepFM model, the model can handle the connection relationship between multi-vendor configurations internally, improving the consistency between request mapping, return mapping, code value transcoding, composite API routing, and deployment / running.

[0019] This invention also integrates the data interface service definition results into the interface sample testing, release flow verification, and interface operation governance chain, enabling publishable data interface services to continue to accept service bus access, operation status recording, and reuse of supplier interface changes. When the content of a supplier interface changes, the interface configuration acceptance parameters in the data interface service definition results can be used to locate and update the relevant configurations, reducing manual troubleshooting and redundant development, and improving the stability and reusability of data interface releases and operations. Attached Figure Description

[0020] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 Here is a flowchart of a method and system for automatically generating data interfaces based on a large model, as proposed in this invention. Figure 2 This is a schematic diagram of the structure of the improved xDeepFM model in the system of the automatic generation method of data interface based on a large model proposed in this invention. Figure 3 This is a schematic diagram of the system structure of a method and system for automatically generating data interfaces based on a large model, as proposed in this invention. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0022] refer to Figure 1 and Figure 2 A method for automatically generating data interfaces based on large models includes the following steps: S1. Collect external data interface information and platform service governance information, clean up interface description noise and merge them into a data interface information set; S2. Call the GPT large model parsing data interface dataset, decompose the interface description content into data interface semantic units, and assemble them into a data interface configuration draft; S3. Perform cross-supplier interface configuration difference correction on the draft data interface configuration, rewrite the supplier-side configuration into the platform standard service definition, and form a unified data interface service configuration object. S4. Organize the unified data interface service configuration object into a composite API configuration item dependency matrix in the context of composite API runtime, and write the interface configuration acceptance parameters into the matrix positions. S5. Combined API configuration item dependency matrix access improves the xDeepFM model. The compressed interaction network CIN rewrites the ordinary feature domain channel feature map into a configuration feature map with the combined API configuration domain as the main index and linked with the supplier domain and the runtime domain. Tensor decomposition convolution kernel reads the index position of the configuration feature map and compresses the configuration outer product tensor, outputting the data interface service definition result. S6. Perform interface sample testing and release flow verification on the data interface service definition results to form a publishable data interface service; S7. The data interface service access interface operation and governance link can be published. The interface operation and governance link takes over the service operation status and reuses the data interface service definition results when the supplier interface changes, forming an operable data interface service.

[0023] In this embodiment, S1 includes: Supplier access data comes from supplier interface documentation, integration test messages, error code descriptions, billing instructions, and interface change notifications. Platform service governance data comes from service catalogs, development configurations, test records, release approval records, service bus records, monitoring records, billing records, and lineage records. Before data is merged, external data service capabilities are verified by service name, service code, interface purpose, and returned object. Data with the same service name and the same returned object are grouped into the same service capability. Data with different service names but the same interface purpose, request object, and returned object are verified again using data resource identifiers. If they match, they are grouped into the same service capability. Data with discrepancies retain their source and are transferred to the data pool awaiting review.

[0024] Interface descriptions are identified by interface address, request method, field descriptions, and return descriptions; call example information is identified by request messages, response messages, success examples, and failure examples; code value descriptions are identified by original business codes, original response codes, and error descriptions; billing descriptions are identified by call counts, billing caliber, balance limits, and frequency control descriptions. The platform categorizes the identified information into four phases: service definition, development and testing, release and operation, and change management. The phase classification results are written into the phase markers of the document paragraphs, and the supplier source, data resource identifier, document version, and document location are written into the source markers.

[0025] Page navigation, button text, blank placeholders, repeated headers and footers, HTML tags, and placeholders without field meaning are removed from parsable text; interface names, field names, field types, field lengths, required fields, field descriptions, sample messages, code value descriptions, billing descriptions, and runtime configuration descriptions are retained. When data is missing, existing data continues to be included in the data interface data set, and missing items are written to the pending data pool; when there are version conflicts, the document version number, release approval record, and change order number are used for verification, and the verified version enters the data interface data set, while the conflicting version enters the version conflict data pool; when there are multiple supplier data under the same service capability, supplier difference texts are not merged, and each supplier's data, carrying its source tag, is included in the data interface data set.

[0026] In this embodiment, S2 specifically includes: Before the data interface dataset enters the GPT large model, the platform encapsulates and parses input packages based on external data service capabilities. External data service capabilities are jointly determined by the service name, interface purpose, request object, return object, and data resource identifier. Data with the same service name and identical return object enters the same parsing input package. Data with different service names but identical interface purpose, request object, and return object are further verified against the data resource identifier; if they match, they enter the same parsing input package. Each parsing input package retains the vendor source and data stage. The vendor source is used to distinguish external interface data from vendors A, B, etc., while the data stage is used to distinguish service definition, development and testing, release and operation, and change management content.

[0027] During GPT large model parsing, the input packets are arranged in the following order: service capability summary, supplier source, interface description, call example content, and platform configuration content. Interface descriptions are identified by interface address, request method, interface purpose, request field descriptions, and return field descriptions; call example content is identified by request messages, response messages, success examples, and failure examples; platform configuration content is identified by test results, release status, combined queries, subscription descriptions, monitoring and billing information, and lineage descriptions. In one implementation, the GPT large model parsing temperature is fixed at 0.2 to avoid different field names resulting from multiple parsings of the same data; the output content only retains basic interface content, interface call content, request example content, response example content, and service governance content.

[0028] Semantic mapping is completed through three checks: service capabilities, supplier origin, and semantic objects. When service capabilities are consistent, request objects, return objects, and code value objects with the same meaning are grouped into the same semantic group. When supplier origins are inconsistent, the semantic group retains the original field names and original code values ​​of each supplier for cross-supplier configuration difference correction in the next processing stage. The data interface configuration draft consists of basic interface content, interface call content, request example content, response example content, and service governance content. Each type of content carries a source tag and a stage tag.

[0029] When the GPT parsing result is empty, the parsing input package is written to the parsing failure pool and the service capabilities, supplier source, and failure text range are recorded. When the sample content is missing, the existing interface basic content and interface call content continue to enter the data interface configuration draft, and the missing sample is written to the sample completion queue. When conflicting descriptions occur in the same parsing input package, the platform retains the supplier source, data stage, and document version, and the conflicting content enters the difference correction stage for processing along with the data interface configuration draft.

[0030] In this embodiment, S3 specifically includes: The cross-vendor configuration correction group is jointly determined by external data service capabilities, vendor sources, and platform phase sources. External data service capabilities are verified through service name, interface purpose, request object, return object, and data resource identifier. Vendor configurations that are all consistent are placed in the same correction group; if inconsistencies exist, the original vendor source and original document location are retained, and the configuration is transferred to the object awaiting review. The platform phase source is used to differentiate between service definition, development / testing, release / operation, and change management content. Content from different phases within the same correction group is stored hierarchically. Service definition content first undergoes platform-wide correction, while development / testing, release / operation, and change management content are added as supplementary content to avoid test samples or operation records overwriting service definition content.

[0031] The platform's standard service definitions are derived from the platform service catalog, external data service definition pages, internal API development configurations, test release configurations, and operational governance configurations. During the calibration process, interface configurations are processed first, followed by service governance configurations. Request fields, return fields, call addresses, request methods, and return types in the interface configurations are converted to platform service definition configuration content; parameter mappings, return mappings, code value transcoding, combined queries, test releases, and operational instructions in the service governance configurations are converted to platform acceptance configuration content. Each conversion retains the supplier's source, original field names, original field paths, original code values, and data stages, ensuring that the platform's standard configurations can be traced back to the original content on the supplier's side.

[0032] In one implementation, when the meanings of paramNo and queryFlag of supplier A are consistent with those of custNo and typeCode of supplier B, the original field names and supplier origins are retained, and they are written into the same platform standard request parameters. When the meanings of retCode, retMsg, name, and status of supplier A are consistent with those of code, message, custName, and custState of supplier B, the original returned field paths are retained, and they are written into the same platform standard returned fields. 0000 and SUCCESS are written as platform success codes, NODATA and 204 are written as platform not found codes, and 1001 and PARAM_ERROR are written as platform parameter error codes. The original code values ​​are entered into the unified data interface service configuration object along with the supplier origin for use in sample testing and runtime tracing.

[0033] The unified data interface service configuration object consists of platform service definition configuration content, platform-accepted configuration content, and supplier source records. When a supplier configuration is missing, the corrected content continues to be entered into the unified data interface service configuration object, while the missing content is written to the object to be supplemented. When the platform standard service definition is not matched, the original supplier configuration is retained and transferred to the manual confirmation object. The manual confirmation object records the service capability, supplier source, missing fields, and original text location. When conflicting configurations occur under the same service capability, they are jointly verified through document stage, document version, and release approval records. The verified content is entered into the unified data interface service configuration object, while the conflicting content is retained as a difference record along with the object.

[0034] In this embodiment, S4 specifically includes: The combined API runtime context is formed by the combined API services already established on the platform, supplier data resource nodes, query strategies, test release status, and runtime governance records. When the unified data interface service configuration object is entered into the matrix, the platform standard service definition content, supplier interface adaptation content, and interface runtime support content are first separated. The platform standard service definition content supports the service objects uniformly exposed by the platform, the supplier interface adaptation content supports the request mapping, return mapping, and code value transcoding of each supplier, and the interface runtime support content supports combined queries, sample tests, release status, service bus, and runtime governance records.

[0035] The dependency matrix for combined API configuration items is organized using a row-column positioning method. The rows contain the platform's standard service definitions, while the columns contain vendor interface adaptation content and interface operation support content. Whether row-side and column-side objects belong to the same external data service capability is verified by checking the service name, interface purpose, request object, return object, and data resource identifier. If they match, it is then determined whether there is a request mapping, return mapping, code value transcoding, combined query, test release, or operation governance support between the row-side and column-side objects. If support exists, the corresponding intersection position is determined as the valid matrix position.

[0036] The valid matrix position is written into the interface configuration acceptance parameters. The interface configuration acceptance parameters record platform configuration items, supplier configuration items, acceptance type, supplier source, stage source, and acceptance destination. The acceptance type is limited to request mapping, return mapping, code value transcoding, combined query, test release, and runtime governance. The acceptance destination points to the interface sample test, release flow verification, or interface runtime governance link. In one implementation, interface priority strategy, traffic routing, no-data routing, and abnormal routing are categorized under combined query acceptance type; successful examples and failed examples are categorized under test release acceptance type; and call volume, call duration, success rate, anomaly rate, billing calculation, and lineage records are categorized under runtime governance acceptance type.

[0037] When row-side and column-side objects are not verified by the same external data service capability, or when field semantics, code value meanings, query objects, test objects, and runtime objects are missing, the corresponding intersection positions are left as empty matrix positions. Empty matrix positions are not written to the interface configuration acceptance parameters; only the supplier source, platform stage source, original data location, and reason for absence are appended. The reason for absence is written as platform definition missing, supplier adaptation missing, runtime acceptance missing, or semantic mismatch. After the matrix is ​​organized, row-side objects, column-side objects, valid matrix positions, interface configuration acceptance parameters, and empty matrix positions together constitute the combined API configuration item dependency matrix.

[0038] In this embodiment, the improved xDeepFM model includes an input embedding layer, a linear part, a compressed interaction network (CIN), a deep neural network part, and an output layer. The compressed interaction network (CIN) includes hidden layer feature maps, outer product tensors, convolutional kernels, and pooling outputs. The hidden layer feature maps are configured with a combination of API configuration domain as the primary index and linked to the configuration feature maps of the supplier domain and the runtime domain. The convolutional kernels consist of a configuration domain kernel, a supplier kernel, and a runtime kernel, forming a tensor decomposition convolutional kernel. A typical xDeepFM model consists of an input embedding layer, a linear part, a compressed interaction network (CIN), a deep neural network, and an output layer. The standard approach treats each feature domain as a parallel field input. The input embedding layer maps discrete features to embedding vectors of the same dimension. The linear part retains first-order contributions. The CIN extracts explicit higher-order interactions through hidden layer feature maps, outer product tensors, convolutional kernels, and pooling outputs. The deep neural network extracts implicit interactions, and the output layer merges the results from all parts. In scenarios where external data interfaces are automatically generated, ordinary field channels can only express the co-occurrence of fields, suppliers, routes, and test or runtime records. They cannot reliably distinguish supplier differences and runtime phase transitions under the same API configuration domain, easily separating request mapping, return mapping, code value transcoding, query strategies, test releases, and runtime governance into ordinary feature combinations.

[0039] The improved xDeepFM model retains the backbone connections of the input embedding layer, linear part, compressed interaction network (CIN), deep neural network, and output layer. The data transmission order is as follows: the combined API configuration dependency matrix enters the input embedding layer; the embedding vectors then enter the linear part, CIN, and deep neural network respectively; the CIN outputs a pooled output; the deep neural network outputs an implicit configuration-related output; and the output layer merges the first-order result, pooled output, and implicit configuration-related output of the linear part to form the data interface service definition result. The improvements are concentrated within the CIN. The hidden layer feature maps are changed from ordinary feature domain channels to configuration feature maps with the combined API configuration domain as the main index, linking the supplier domain and runtime domain. The convolutional kernels consist of a configuration domain kernel, a supplier kernel, and a runtime kernel, forming a tensor decomposition convolutional kernel. The input embedding layer, linear part, deep neural network, and output layer perform the conventional forward pass.

[0040] The combined API configuration item dependency matrix is ​​processed into a fixed-length record sequence before being input into the model. A record is generated for each valid matrix position, containing the platform configuration item index, supplier configuration item index, combined API configuration domain index, supplier index, runtime phase index, acceptance type index, and interface configuration acceptance parameters. Empty matrix positions generate empty records with empty markers. Discrete indices are then used to obtain embedding vectors from tables after entering the input embedding layer. Boolean values, enumerated values, and continuous values ​​in the interface configuration acceptance parameters are first converted into numerical vectors and then linearly mapped to the same embedding dimension. In one implementation, the embedding dimension of each record can be 64, and the shape of a single batch input is B×N×64, where B is the batch size and N is the number of records after padding within the same batch. When there are fewer than N records, zero vectors are used for padding, and the padding positions are masked by empty markers to prevent padding records from participating in the output layer result merging.

[0041] Model parameters are obtained through training on historical interface configuration samples. Training data comes from platform-released service definitions, manually approved request parameter mappings, returned data item mappings, business code and response code encoding, combined API query strategies, successful and failed example test records, service bus call records, monitoring and billing records, lineage records, and supplier change tickets. Training labels are generated from released service configurations that have passed regression testing. Label content includes valid connection location, connection type, platform standard fields, platform standard code values, route switching results, release test results, and change-affected objects. Manually approved records that match test-passed records are marked as valid labels; when a manually approved record passes but the test fails, the reason for failure is entered into the exception label; supplier information that is missing or conflicting and unconfirmed is not included in the training set, but only in the blank processing samples during verification.

[0042] During training, the parameters are updated jointly by the input embedding layer, the linear part, the compressed interactive network (CIN), the deep neural network part, and the output layer. The loss function consists of the acceptance position binary classification loss, acceptance type classification loss, standard field classification loss, standard code value classification loss, and release / run consistency loss. The acceptance position binary classification loss uses valid matrix positions as 1 and empty matrix positions as 0, and calculates the binary cross-entropy between the model output acceptance position probability and the label value; the acceptance type classification loss uses request mapping, return mapping, code value transcoding, combined query, test release, and run governance as classification labels, and calculates the cross-entropy between the model output acceptance type probability and the label; the standard field classification loss uses the platform's standard fields that have been manually approved as labels to calculate the cross-entropy; the standard code value classification loss uses standard code values ​​such as platform success, not found, parameter error, and supplier anomaly as labels to calculate the cross-entropy. The release-run consistency loss is calculated by marking samples that pass the testing phase and do not exhibit the same anomaly during the runtime phase as 1, and samples that pass the testing phase but exhibit field mapping anomalies, code value transcoding anomalies, or routing anomalies during the runtime phase as 0. The consistency probability output by the model is used to calculate the binary cross-entropy with the marked values. In one implementation, the total loss can be the sum of 0.25 times the binary classification loss for receiving positions, 0.25 times the classification loss for receiving types, 0.2 times the classification loss for standard fields, 0.15 times the classification loss for standard code values, and 0.15 times the release-run consistency loss. These weights are derived from the initial allocation of the training set. If the pass rate of the combined API routing test on the validation set is lower than the request mapping accuracy and return mapping accuracy for three consecutive rounds, the release-run consistency loss weight is increased by 0.05, and 0.05 is deducted from the standard field classification loss weight, keeping the total weight at 1.

[0043] In one implementation, the optimizer uses AdamW, with an initial learning rate of 0.001, weight decay of 0.0001, batch size of 128, and a maximum of 80 training epochs. Training stops when the total validation set loss decreases by less than 0.001 for five consecutive epochs, or when the request mapping accuracy, return mapping accuracy, code value transcoding integrity, and combined API routing test pass rate do not improve for five consecutive epochs. The model parameters with the highest overall validation set performance are then retained. After training, the parameters of the configuration domain kernel, supplier kernel, and runtime kernel are fixed and enter the inference process. When new supplier data is added to the model, only a new supplier index and corresponding embedding vector are generated. Existing configuration domain kernels and runtime kernels are reused, thus maintaining consistency in the internal computational paths between the combined API configuration domain, supplier differences, and runtime integration.

[0044] In this embodiment, S5 specifically includes: The input embedding layer consists of a configuration domain embedding table, a supplier embedding table, a runtime embedding table, a service type embedding table, and a parameter linear mapping matrix. After reading the combined API configuration item dependency matrix, the valid and missing matrix positions in the matrix are converted into a fixed-length record sequence. Each valid record contains a platform configuration item index, a supplier configuration item index, a combined API configuration domain index, a supplier index, a runtime index, a service type index, and interface configuration service parameters; missing records retain the platform configuration item index, supplier index, runtime index, and a missing marker. The combined API configuration domain index is used to distinguish between request mapping, return mapping, code value transcoding, combined queries, test release, and runtime governance. The runtime index is used to distinguish between service definition, development testing, release operation, and change management. Discrete indexes retrieve the embedding vector from the corresponding embedding table. Boolean values ​​in the interface configuration service parameters are converted to 0 or 1, enumerated values ​​are converted to enumeration numbers, and continuous values ​​are normalized using the minimum and maximum values ​​of the same type of parameters in the training set, and then mapped to parameter vectors through the parameter linear mapping matrix. The discrete embedding vector and parameter vector are concatenated and then subjected to the same linear transformation. The linear transformation performs matrix multiplication, bias superposition, and ReLU compression, and the output dimension is consistent with the model embedding dimension. In one implementation, the model embedding dimension can be 64, and the shape of a single batch input is B×N×64, where B represents the batch number and N represents the number of records after padding within the same batch. Positions with fewer than N records are filled with zero vectors, and the source of the gap is retained by a gap marker.

[0045] The linear part consists of a first-order weight matrix and a first-order bias. After reading the interface configuration acceptance parameters, it extracts the acceptance type, supplier source, operation stage, and parameter validity flag from each record. The acceptance type embedding, supplier embedding, operation stage embedding, and parameter vector are concatenated into a first-order input vector. The first-order input vector is multiplied by the first-order weight matrix and then superimposed with the first-order bias to obtain the first-order configuration contribution for each record. When multiple supplier records exist under the same platform configuration item, the first-order configuration contributions are first accumulated along the supplier dimension, and then along the operation stage dimension to form the basic configuration contribution. The first-order configuration contribution for vacant records remains 0, and the vacancy flag is entered into the deep neural network part to prevent vacant positions from being mistakenly written as valid acceptances.

[0046] The Compressed Interactive Network (CIN) comprises hidden layer feature maps, outer product tensors, convolutional kernels, and pooling outputs. After reading the embedding vectors formed by the input embedding layer, the hidden layer feature maps are organized into a configuration feature map. The configuration feature map consists of a configuration domain axis, a supplier axis, a runtime stage axis, and a channel dimension. The configuration domain axis corresponds to the combined API configuration domain index, the supplier axis corresponds to the supplier index, the runtime stage axis corresponds to the runtime stage index, and the channel dimension carries 64 dimensions of the embedding vectors. The embedding vectors corresponding to valid matrix positions are written to the index positions of the same configuration domain, the same supplier, and the same runtime stage in the configuration feature map. When multiple valid records exist at the same index position, embedding vectors with the same acceptance type are averaged. Embedding vectors with different acceptance types are written to adjacent channel segments in a fixed order: request mapping, return mapping, code value transcoding, combined query, test release, and runtime governance. Empty matrix positions are not filled with valid embedding values; only empty markers and empty sources are written, ensuring that the configuration feature map retains missing acceptance in the index space.

[0047] After the hidden layer feature maps are rewritten from ordinary feature domain channels to configuration feature maps, the Compressed Interaction Network (CIN) no longer arranges explicit interaction objects by ordinary field numbers, but instead arranges them by the combined API configuration domain as the main index. The first-layer configuration feature map comes from the output of the input embedding layer, and the l-th layer configuration feature map comes from the convolutional compression result of the (l-1)-th layer configuration feature map. Each layer keeps the configuration domain axis, supplier axis, and runtime stage axis unchanged, updating only the configuration interaction features within the channel dimension. This arrangement ensures that the content received by different suppliers and different runtime stages under the same request mapping, return mapping, or code value transcoding domain remains in adjacent index positions, facilitating the outer product tensor and convolution kernel to read supplier differences and stage reception under the same business semantics.

[0048] The configuration outer product tensor is constructed jointly by the current layer configuration feature map and the input layer configuration feature map. Each configuration domain, supplier, and runtime stage position in the current layer configuration feature map reads the current interaction vector, while each supplier and runtime stage position in the same configuration domain in the input layer configuration feature map reads the original embedding vector. Each dimension of the current interaction vector is multiplied by each dimension of the original embedding vector to form a local outer product matrix for that configuration domain. These local outer product matrices are arranged along the supplier axis and the runtime stage axis to form the configuration outer product tensor. Valid matrix positions generate outer product values, while empty matrix positions retain a missing marker. When a supplier lacks a return mapping or code value transcoding, the corresponding supplier axis position is not padded with 0 values ​​for multiplication but is retained as an empty matrix position for miss handling and deep neural network reading.

[0049] The convolutional kernel consists of a configuration domain kernel, a supplier kernel, a runtime kernel, and a convolutional bias. These three types of kernels together form a tensor decomposition-based convolutional kernel. The configuration domain kernel reads the main index range of the configuration outer product tensor belonging to the same combined API configuration domain. The supplier kernel reads the supplier difference positions within the same main index range. The runtime kernel reads the runtime continuation positions within the same main index range. The parameters of the three types of convolutional kernels are obtained from the model training phase and are fixed for the inference process after training. Convolutional compression is performed in the order of configuration domain, supplier, and runtime. The configuration domain kernel is first multiplied with the configuration domain slice of the configuration outer product tensor and accumulated to obtain the configuration domain response. The supplier kernel is then multiplied with the supplier axis slice in the configuration domain response and accumulated to obtain the supplier difference response. The runtime kernel continues to multiply with the runtime axis slice in the supplier difference response and accumulates it. After adding the convolutional bias, the tensor position response is obtained. In one implementation, the tensor position response is ReLU compressed, with responses less than 0 set to 0 and responses greater than 6 truncated to 6, so that abnormally large individual configuration differences do not overwrite the acceptance information of other suppliers and operational phases within the same configuration domain.

[0050] Tensor positions that are jointly hit by tensor decomposition convolutional kernels form valid convolutional positions, and the tensor position responses of valid convolutional positions are written into the updated configuration feature map. Tensor positions not jointly hit by configuration domain kernels, vendor kernels, and runtime kernels are not included in the convolutional response accumulation; the original missing markers and missing sources are written back as missing matrix positions. The reasons for missing positions are configuration domain misses, vendor misses, and runtime misses. Configuration domain misses indicate that the platform configuration item lacks a corresponding combined API configuration domain; vendor misses indicate missing vendor adaptation content; and runtime misses indicate missing test release or runtime governance support. The written-back missing matrix positions remain in the configuration feature map index space to prevent the Compressed Interaction Network (CIN) from misjudging missing configurations as low-intensity valid configurations.

[0051] The pooling output consists of the supplier difference pooling result and the runtime phase acceptance pooling result. When the Compressed Interaction Network (CIN) performs pooling on the updated configuration feature map, it first maximizes the effective convolution positions on the supplier axis for the same configuration domain and the same runtime phase to obtain the supplier difference pooling result. Then, it averages the supplier difference pooling results on the runtime phase axis for the same configuration domain to obtain the runtime phase acceptance pooling result. Maxim pooling retains the most significant supplier difference within the same configuration domain, while average pooling retains the overall acceptance strength along the release runtime chain. Missing matrix positions do not participate in the maximum and average calculations; when a configuration domain is entirely empty, the pooling output for that configuration domain remains 0, and the source of the emptiness is passed to the deep neural network part.

[0052] The deep neural network component includes a multi-layer fully connected network and an implicit configuration association output. After reading the embedding vector corresponding to the missing matrix position and the source of the missing information, the implicit configuration association output is formed. The configuration domain embedding, supplier embedding, runtime stage embedding, and missing reason embedding of the missing record are concatenated and then fed into the multi-layer fully connected network. In one embodiment, the multi-layer fully connected network can adopt a three-layer structure of 128-dimensional, 64-dimensional, and 32-dimensional structures. Each layer performs matrix multiplication, bias stacking, and ReLU compression, finally outputting a 32-dimensional implicit configuration association vector. This vector is used to express the implicit association between the missing configuration and existing configurations. For example, when the same supplier requests a complete mapping but returns a missing mapping, the model uses existing records under the same configuration domain and runtime stage to form an association hint for the missing position.

[0053] The output layer includes linear readout and result merging. After merging the basic configuration contribution, pooled output, and implicit configuration-related output, a data interface service definition result is formed. The output layer first concatenates the three types of output into a unified readout vector, and then obtains the candidate result scores of each configuration item through linear transformation. After the candidate result scores are normalized by Softmax, the configuration item corresponding to the maximum score is taken as the output configuration item. In one embodiment, the maximum score threshold can be 0.6. This threshold is jointly determined by the request mapping accuracy rate, return mapping accuracy rate, code value transcoding integrity rate, and combined API routing test pass rate in the verification set. When the threshold is increased from 0.5 to 0.6, the number of manually confirmed objects increases but the number of incorrectly written configurations decreases. When the threshold is further increased to 0.7, there are too many manually confirmed objects, which reduces the efficiency of automatic generation. Therefore, 0.6 is taken as the boundary between automatic writing and manual confirmation. When the maximum score is lower than 0.6, the corresponding configuration item enters the manually confirmed object and is not directly written to the data interface service definition result. The data interface service definition results include platform standard request parameters, supplier request mappings, platform standard return fields, supplier return mappings, business code encoding, response code encoding, combined API query strategies, interface sample test entry points, and operation governance acceptance entry points. Manually confirmed objects corresponding to missing matrix positions are also output with the results, facilitating completion by the test and release module.

[0054] Compared to the standard xDeepFM model, the improvements of the improved xDeepFM model lie in the simultaneous modification of the index space and convolution parameter space of the Compressed Interaction Network (CIN). The standard xDeepFM model treats fields, suppliers, tests, and runtime content as parallel fields, with higher-order interactions only expressing the strength of feature co-occurrence, lacking a fixed endpoint between the combined API configuration domain, supplier differences, and runtime transitions. The improved model, however, directly maps the index space of the hidden layer feature maps to the combined API configuration domain, supplier, and runtime stages, with each outer product and convolution occurring at a traceable configuration semantic location. The standard convolutional kernel only learns compressed parameters from the results of ordinary field interactions, making it difficult to distinguish between different configuration issues such as request mapping errors, missing return paths, and route disconnections. The tensor decomposition-based convolutional kernel splits the convolution parameters into three directions: configuration domain, supplier, and runtime stage, enabling the model to simultaneously distinguish supplier field differences and release / running transition differences within the same configuration domain. This transformation changes the data interface service definition results from field-level generated results to configuration results that can directly undertake sample testing, release verification, runtime governance, and vendor change reuse. The core value lies in transforming the composite API configuration dependencies from external manual verification objects into high-order interactive objects that are computable, rewritable, and traceable within the CIN.

[0055] In this embodiment, S6 includes: The interface sample content comes from the request samples, response samples, success examples, failure examples, and integration records retained in the data interface service definition results. Success examples are used to verify whether the platform's standard request parameters, after being mapped by the supplier's request, can form a callable message, and to verify whether the supplier's returned content, after return mapping and code value transcoding, can form the platform's standard output. Failure examples are used to verify the standard business codes, standard response codes, and error descriptions under scenarios such as missing parameters, incorrect parameters, no results, timeouts, supplier anomalies, insufficient balance, and frequency control restrictions. When sample content is missing, existing configurations continue to enter the test task, and missing samples are written into the test difference content and not included in the release candidate content.

[0056] The platform test channel reads the request method, test address, parameter mapping, return mapping, code value transcoding, and combined API routing configuration from the data interface service definition result, generates test messages, and connects them to the test environment gateway. After completing authentication and message format verification, the test environment gateway calls the supplier test interface or platform simulation interface. The returned message then undergoes return mapping and transcoding processing to form the platform's standard output. Successful examples are judged as successful if the business code is successful, the response code is normal, and the required returned data items exist; failed examples are judged as successful if the error type, error description, and route destination are consistent with the failure scenario. If required parameters are not mapped, the return field path is not hit, the original code value is not transcoded, or the route destination is inconsistent, the test result is recorded as failed, and the differences are filled back into the data interface service definition result.

[0057] Test results are populated into the test result field of the data interface service definition and checked against the interface configuration parameters item by item. Parameter mapping is checked against platform standard parameters and supplier actual parameters; return mapping is checked against platform standard return fields and supplier return field paths; code value conversion is checked against original code values ​​and platform standard code values; and combined API routing is checked against the trigger destinations of interface priority, no-data routes, and abnormal routes. Configuration parameters that match are marked as passing the test; configuration parameters that do not match are appended with the test discrepancies and returned for correction.

[0058] In one implementation, the release status remains unreleased until test results are generated; when all test results pass and there are no unprocessed test discrepancies, the release status enters the "releasing" phase; after approval, the release status changes to "released"; if approval is rejected, the release status changes to "release rejected"; when the service is deprecated, the release status changes to "offline". Release candidate content consists of the data interface service definition results that have passed testing, the "releasing" status, and the test results. Publishable data interface services include service definition content, vendor mapping content, transcoding content, combined API routing content, sample test results, and release status, serving as the service object before the interface operation governance link is accessed.

[0059] In this embodiment, S7 specifically includes: Before the data interface service can be accessed and the governance chain is run, the service definition content, publication status, and combined API routing content are registered under the same service code. The service definition content is written to the service directory, the publication status is written to the subscription directory, and the combined API routing content is written to the service bus configuration area. These three types of content are associated through the service code and the combined API identifier. When the publication status is published, the service code is unique, the unified access URL is valid, the combined API route has a callable vendor node, and the subscribed application has the calling permission, the service bus access verification passes. If any verification object fails, the difference is written to the access verification record, and the service remains in an uncallable state.

[0060] After the service bus is opened for invocation, request messages are parsed, authenticated, routed, and logged. Monitoring and statistics results are generated from call volume, call duration, number of successful calls, number of abnormal calls, and call details. The success rate is calculated by dividing the number of successful calls by the total number of calls, and the exception rate is calculated by dividing the number of abnormal calls by the total number of calls. Billing and accounting results are generated by multiplying the number of vendor calls by the corresponding billing price and then summing them. Insufficient balance, frequency control restrictions, and vendor refusal to call are written as exception types. Lineage analysis results record the dependency paths between services, data resources, vendor nodes, subscription applications, and composite APIs. Monitoring and statistics results, billing and accounting results, and lineage analysis results are jointly written into the service runtime status, which serves as the comparison object when vendors change and reuse.

[0061] Supplier changes are identified through supplier interface change notifications, new versions of interface documentation, operational anomaly records, and change orders. Change types include interface address changes, request field changes, return field changes, original code value changes, billing caliber changes, and supplier node shutdowns. The platform compares each supplier change with the interface configuration parameters associated with the data interface service definition. If the supplier source is consistent and the platform configuration item, supplier configuration item, or acceptance type corresponds to the change, it is considered a match. If the supplier source, configuration item, or acceptance type differs, it is considered a miss. Matched configuration parameters are updated according to the change, while missed parameters retain their original values, and the reason for the miss is recorded.

[0062] The updated request mappings, response mappings, code value transcoding, combined API routing, or billing configurations are written back to the data interface service definition results, and the service directory, service bus configuration area, and subscription directory are refreshed simultaneously. After the write-back is completed, the service bus access verification is re-executed. If the verification passes, a runnable data interface service is formed; if the verification fails, the changed content, hit parameters, and failure reasons are entered into the change review object. The runnable data interface service includes service definition content, current publication status, current combined API routing content, service running status, and change write-back records, and is used to continue to undertake platform calls, monitoring, billing, lineage analysis, and operation and maintenance processing.

[0063] refer to Figure 3 A data interface automatic generation system based on a large model includes the following modules: The data collection module is used to organize external data interface data and platform service governance data, remove descriptive interference content that does not participate in interface configuration, and form a data interface data set that can be handled by the semantic parsing module. The semantic parsing module is used to call the GPT large model to parse the data interface dataset and convert the interface description content into a data interface configuration draft that can distinguish the supplier source, interface call content and platform governance content. The difference correction module is used to correct cross-vendor configuration differences in the draft data interface configuration and convert the vendor-side configuration into the platform standard service definition, forming a data interface service configuration object that can uniformly accept different vendor interfaces. The matrix organization module is used to organize the unified data interface service configuration objects in the context of combined API operation, and organize the configuration content between service definition, vendor adaptation and operation into a combined API configuration item dependency matrix. The model generation module is used to input the combined API configuration item dependency matrix into the improved xDeepFM model, generate configuration feature maps by the compressed interaction network CIN and compress the configuration outer product tensor, and output data interface service definition results that can support test release and runtime governance. The test and release module is used to perform interface sample tests and release flow verification on the data interface service definition results, verify the consistency of the configuration results in calling, returning, transcoding and routing scenarios, and form a publishable data interface service. The operation governance module is used to connect publishable data interface services to the interface operation governance link, take over the service operation status, and reuse the data interface service definition results when the supplier interface changes, so as to form an operable data interface service.

[0064] Example 1: To verify the feasibility of this invention in practice, it was applied to a scenario of automatic generation and operation governance of data interfaces on an external data platform. The data service platform includes a management center, a capability center, and a portal. The management center maintains service definitions, test releases, operation monitoring, billing calculations, and lineage analysis. The capability center handles service catalogs, data resources, and combined API routing configurations. The portal handles service retrieval, service subscription, and call entry points for subscribed applications. The platform connects to external interface call links via a service bus and exchanges service catalogs, data resources, approval workflows, and change orders with metadata management, data asset management, project management, and collaborative office systems. In the data application layer development process, the mapping import results and service development configurations enter the testing phase together. After passing the tests, they enter the production phase and are integrated with the service testing, release approval, and service subscription processes. The platform includes a data collection module, a semantic parsing module, a difference correction module, a matrix organization module, a model generation module, a test release module, and an operation governance module. The platform needs to simultaneously access vendors A and B for a certain external data query service and provide a unified access interface to internal business systems. The original method primarily relied on implementation personnel manually reading the interface documentation, maintaining service ID, service code, service name, URL, service group, return type, request method, service description, data resources, creator, creation time, initial test result value, and initial release status value on the service development page. This involved configuring request parameter JSON, configuring mapping relationship JSON, returning data item JSON, returning data item mapping relationship JSON, transcoded business code JSON, transcoded response code JSON, query strategy, success examples, and failure examples. Supplier A actually requested the fields paramNo and queryFlag, while Supplier B actually requested the fields custNo and typeCode. Supplier A returned the fields retCode, retMsg, name, and status, while Supplier B returned the fields code, message, custName, and custState. Supplier A returned 0000 for success, NODATA for no result, and 1001 for parameter errors, while Supplier B returned SUCCESS for success, 204 for no result, and PARAM_ERROR for parameter errors. Due to cross-vendor differences in request parameters, return fields, code value systems, routing strategies, and billing instructions, manual configuration can easily lead to issues such as missing parameter mappings, incorrect return hierarchy paths, incomplete transcoding rules, inconsistent API switching rules, and difficulty in locating the scope of impact of post-release changes.

[0065] In this scenario, the data collection module gathers interface specifications, call examples, error code descriptions, billing descriptions, and platform service governance data from Supplier A and Supplier B, cleaning up page display markers, blank placeholders, and duplicate descriptions to form a data interface data set. The semantic parsing module uses the GPT large model to parse the data interface data set, breaking down the interface specifications, call examples, and platform configuration content into data interface semantic units, and assembling them into a data interface configuration draft. The difference correction module reads the supplier source and platform stage source from the data interface configuration draft, corrects cross-supplier interface configuration differences, and rewrites the supplier-side request fields, return fields, business codes, response codes, query strategies, and billing descriptions into platform standard service definitions, forming a unified data interface service configuration object. The matrix organization module processes the unified data interface service configuration object in the context of combined API operation. It organizes the platform standard request parameters, supplier parameter mapping, unified return fields, supplier return field paths, code value transcoding, interface priority strategy, traffic routing strategy, no data routing, abnormal routing, test release status, and operation governance nodes into a combined API configuration item dependency matrix, and writes the interface configuration acceptance parameters in the matrix positions to form a computable acceptance relationship between request mapping, return mapping, transcoding, routing, test release, and operation governance.

[0066] The model generation module integrates the combined API configuration item dependency matrix into the improved xDeepFM model. The input embedding layer generates embedding vectors corresponding to the configuration domain, supplier, and runtime phase based on the matrix position. The linear part reads the interface configuration acceptance parameters to form the basic configuration contribution. The compressed interaction network (CIN) reads the embedding vectors and rewrites the ordinary feature domain channel feature maps into configuration feature maps with the combined API configuration domain as the main index and linked to the supplier and runtime phase domains. This ensures that supplier differences and runtime acceptance under the same combined API configuration domain are jointly entered into the configuration outer product tensor. The tensor decomposition convolution kernel reads the tensor positions in the configuration outer product tensor that are jointly hit by the configuration domain kernel, supplier kernel, and runtime phase kernel, and performs convolution compression, outputting the data interface service definition result. The test and release module generates successful and failed examples based on the data interface service definition result, verifying whether the standard request parameters can correctly call the supplier interface via the configuration mapping relationship JSON, and verifying whether the returned data item mapping relationship JSON, the transcoded business code JSON, and the transcoded response code JSON can generate the platform's standard output. After passing the test, a publishable data interface service is formed. The operation governance module manages the access interface for publishable data interface services, executes request parsing, authentication, routing, and logging on the service bus, monitors and manages statistics on call volume, call duration, success rate, exception rate, and call details, generates billing statistics and cost accounting results, and manages the dependency relationships between services, data resources, subscription applications, and supplier nodes. When a new supplier C with the same business capabilities is added, or when the supplier's interface address, field definitions, return structure, error code rules, and billing method change, the operation governance module reuses the interface configuration parameters in the data interface service definition result, locates the configuration items that need to be adjusted synchronously, and writes the updated configuration parameters back to the data interface service definition result, forming a runnable data interface service.

[0067] To verify the implementation effect, 48 external data query services, 126 supplier interfaces, and 384 interface descriptions and sample messages were selected as test objects. The manual configuration method, the direct generation method of the GPT large model, and the method of this invention were compared. The statistical results are shown in Table 1 below: Table 1. Comparison of the effectiveness of automatic data interface generation methods in the governance of composite API configurations.

[0068] As can be seen from the data in Table 1 above, the method of this invention outperforms both manual configuration and the direct generation of the GPT large model in terms of interface configuration efficiency, configuration accuracy, combined API route verification, and vendor change reuse. Under the manual configuration method, the average configuration time for a single service is 46.8 minutes, the first-time accuracy rate for request parameter mapping is 82.3%, and the first-time accuracy rate for return field mapping is 79.8%. This indicates that relying solely on implementers reading the interface documentation and manually maintaining the JSON configuration is easily affected by inconsistencies in vendor field naming, return hierarchy, and code value systems, resulting in a long configuration cycle and a high risk of rework. The direct generation of the GPT large model reduces the average configuration time for a single service to 21.3 minutes and increases the first-time accuracy rate for request parameter mapping to 90.5%, indicating that the large model has good semantic parsing capabilities for interface descriptions and call examples. However, it lacks modeling of the configuration item inheritance relationship in the context of combined API operation, resulting in a combined API route test pass rate of only 86.7%, and the average time for locating the impact of changes is still 27.8 minutes. The method of this invention further organizes the draft data interface configuration obtained from the parsing of the GPT large model into a dependency matrix of combined API configuration items. By improving the configuration feature map of the compressed interaction network CIN in the xDeepFM model and the high-order connection relationship between request mapping, return mapping, code value transcoding, routing strategy and runtime stage, the average configuration time of a single service is further reduced to 11.6 minutes, the first-time accuracy of request parameter mapping reaches 96.1%, the first-time accuracy of return field mapping reaches 94.7%, the code value transcoding configuration completeness rate reaches 97.2%, the combined API routing test pass rate reaches 95.8%, and the average time for adding new suppliers is reduced to 34.5 minutes. This shows that the invention not only improves the efficiency of automatic interface generation, but also enhances the consistency and reusability of multi-supplier combined API configuration.

[0069] This embodiment uses an external data query service from an external data platform as the application object, demonstrating the adaptation process of this invention to the actual product process. The data collection module first gathers the interface descriptions, call examples, error code descriptions, billing descriptions, and platform service governance data of supplier A and supplier B, and cleans up page tags, blank placeholders, and duplicate content to form a data interface data set that can be parsed by the GPT large model; the semantic parsing module decomposes the interface description into data interface semantic units to form a data interface configuration draft; the difference correction module further unifies supplier A's paramNo, queryFlag and supplier B's custNo, typeCode to the platform standard request parameter standard, unifies retCode, retMsg, name, status and code, message, custName, custState to the platform standard return field standard, and converts 0000, SUCCESS, NODATA, 204, 1001, and PARAM_ERROR into platform internal standard code values. Building upon this foundation, the matrix organization module organizes service basic attributes, request parameter JSON, configuration mapping relationship JSON, returned data item JSON, returned data item mapping relationship JSON, transcoded business code JSON, transcoded response code JSON, interface priority strategy, traffic routing strategy, no data route, abnormal route, test release status, and runtime governance nodes into a combined API configuration item dependency matrix. The model generation module uses the improved xDeepFM model to output the data interface service definition results. The test release module verifies scenarios such as parameter errors, no results, timeouts, and supplier anomalies through successful and failed examples. The runtime governance module connects to the service bus, monitoring management, billing management, and lineage management, and reuses existing configuration parameters when a new supplier C is added or the supplier interface changes, thereby achieving a complete closed loop of data interface definition, testing, release, operation, and change reuse.

[0070] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for automatically generating data interfaces based on large models, characterized in that, Includes the following steps: S1. Collect external data interface information and platform service governance information, clean up interface description noise and merge them into a data interface information set; S2. Call the GPT large model parsing data interface dataset, decompose the interface description content into data interface semantic units, and assemble them into a data interface configuration draft; S3. Perform cross-supplier interface configuration difference correction on the draft data interface configuration, rewrite the supplier-side configuration into the platform standard service definition, and form a unified data interface service configuration object. S4. Organize the unified data interface service configuration object into a composite API configuration item dependency matrix in the context of composite API runtime, and write the interface configuration acceptance parameters into the matrix positions. S5. Combined API configuration item dependency matrix access improves the xDeepFM model. The compressed interaction network CIN rewrites the ordinary feature domain channel feature map into a configuration feature map with the combined API configuration domain as the main index and linked with the supplier domain and the runtime domain. Tensor decomposition convolution kernel reads the index position of the configuration feature map and compresses the configuration outer product tensor, outputting the data interface service definition result. S6. Perform interface sample testing and release flow verification on the data interface service definition results to form a publishable data interface service; S7. The data interface service access interface operation and governance link can be published. The interface operation and governance link takes over the service operation status and reuses the data interface service definition results when the supplier interface changes, forming an operable data interface service.

2. The method for automatically generating data interfaces based on a large model according to claim 1, characterized in that, S1 includes reading supplier access information and platform service governance information, organizing interface descriptions, call examples, code value descriptions, billing descriptions and platform-side configuration information according to external data service capabilities, deleting page display tags, blank placeholder content and duplicate description content, writing source tags and stage tags, and forming a data interface data set.

3. The method for automatically generating data interfaces based on a large model according to claim 1, characterized in that, S2 specifically includes: S21, GPT large model reads data interface data set, and classifies parsable text into the same parsing task according to the external data service capabilities; S22. Within the parsing task, identify the interface description segment, the call sample segment, and the platform configuration segment, extract the interface call content, the sample message content, and the service governance content, and retain the source tag and the stage tag; S23. Establish semantic correspondences for the extracted content according to the same external data service capabilities; The S24 and GPT large models assemble semantic correspondences into a data interface configuration draft, and retain supplier sources and platform stage sources in the data interface configuration draft.

4. The method for automatically generating data interfaces based on a large model according to claim 1, characterized in that, S3 specifically includes: S31. Read the supplier source and platform stage source in the draft data interface configuration, and establish a cross-supplier configuration correction group according to the same external data service capability; S32. Perform platform-level correction on the interface configuration and service governance configuration in the cross-vendor configuration correction group, and rewrite the vendor-side configuration into platform service definition configuration content and platform-accepted configuration content. S33. Merge the platform service definition configuration content and the platform undertaking configuration content according to the same external data service capability, and retain the supplier source to form a unified data interface service configuration object.

5. The method for automatically generating data interfaces based on a large model according to claim 1, characterized in that, S4 specifically includes: S41. Read the unified data interface service configuration object and verify the platform definition content, supplier adaptation content and runtime acceptance content according to the combined API runtime context. S42. Write the platform definition content into the row side of the combined API configuration item dependency matrix, and write the supplier adaptation content and runtime acceptance content into the column side of the combined API configuration item dependency matrix. S43. At the intersection of the row and column sides, verify the configuration acceptance content under the same external data service capability. If the position is hit, write the interface configuration acceptance parameters. If the position is not hit, leave it as an empty matrix position. S44. Attach the corresponding source content to the empty matrix positions to form a combined API configuration item dependency matrix.

6. The method for automatically generating data interfaces based on a large model according to claim 1, characterized in that, The improved xDeepFM model includes an input embedding layer, a linear part, a compressed interaction network (CIN), a deep neural network part, and an output layer. The compressed interaction network (CIN) includes hidden layer feature maps, outer product tensors, convolutional kernels, and pooling outputs. The hidden layer feature maps are set to be configured with a combination of API configuration domain as the main index and linked with the configuration feature maps of the supplier domain and the runtime domain. The convolutional kernel is composed of a configuration domain kernel, a supplier kernel, and a runtime kernel, forming a tensor decomposition convolutional kernel.

7. The method for automatically generating data interfaces based on a large model according to claim 1, characterized in that, S5 specifically includes: S51. The input embedding layer reads the combined API configuration item dependency matrix, generates an embedding vector corresponding to the configuration domain, supplier and runtime phase according to the matrix position, and reads the interface configuration parameters in the linear part to form the basic configuration contribution. S52. The Compressed Interactive Network (CIN) reads the embedded vector, replaces the ordinary feature domain channels of the hidden layer feature map with the combined API configuration domain as the main index and links the supplier domain and the runtime domain, and writes the interface configuration acceptance parameters into the index position corresponding to the matrix position in the configuration feature map. S53. Use configuration feature maps instead of ordinary feature maps to participate in the construction of outer product tensors. Supplier differences and runtime phases under the same combined API configuration domain are jointly entered into the configuration outer product tensor. Missed index positions are retained as empty matrix positions along the original matrix positions. S54. The convolutional kernel is split into configuration domain kernel, supplier kernel and runtime kernel. The configuration domain kernel limits the main index range of the configuration outer product tensor, the supplier kernel limits the range of supplier differences, and the runtime kernel limits the runtime acceptance range. The three types of convolutional kernels together form the tensor decomposition convolutional kernel. S55. Tensor decomposition convolution kernels read the tensor positions in the configuration outer product tensor that are hit by all three types of convolution kernels and perform convolution compression. The tensor positions that are not hit are written back as empty matrix positions to form an updated configuration feature map. S56. The Compressed Interaction Network (CIN) performs pooling on the updated configuration feature map and forms a pooled output. The deep neural network part reads the embedding vector corresponding to the position of the missing matrix to form an implicit configuration association output. The output layer merges the basic configuration contribution, the pooled output, and the implicit configuration association output to form the data interface service definition result.

8. The method for automatically generating data interfaces based on a large model according to claim 1, characterized in that, S6 includes reading the data interface service definition result, organizing the interface sample content and the release status content into an interface release verification task, calling the platform test channel to execute successful example tests and failed example tests, generating test results, filling the test results back into the data interface service definition result, verifying the consistency between the test results and the interface configuration acceptance parameters associated with the data interface service definition result, and determining the release candidate content corresponding to the release status and test results as a releaseable data interface service.

9. The method for automatically generating data interfaces based on a large model according to claim 1, characterized in that, Specifically, S7 includes: S71. Read the publishable data interface service and register the service definition content, publishing status and combined API routing content to the interface operation governance link; S72. The interface operation governance link performs service bus access verification. After the verification is passed, the interface call is opened and the service operation details are recorded. S73. Summarize service operation details and associate monitoring statistics, billing and accounting results and lineage analysis results with the same publishable data interface service to form the service operation status; S74. When the supplier interface changes, read the supplier's changed content and compare it with the interface configuration acceptance parameters associated with the data interface service definition result to locate the configuration acceptance parameters that need to be adjusted synchronously. S75. Retain the configuration acceptance parameters that were not hit, update the configuration acceptance parameters that were hit according to the supplier's changes, and write the updated configuration acceptance parameters back to the data interface service definition result to form a runnable data interface service.

10. The automatic data interface generation system based on a large model according to claim 1, characterized in that, The method for automatically generating a data interface based on a large model according to any one of claims 1 to 9 is characterized by comprising the following modules: The data collection module is used to organize external data interface data and platform service governance data, remove interfering content from the interface descriptions, and form a data interface data set. The semantic parsing module is used to call the GPT large model parsing data interface dataset and convert the interface description content into a data interface configuration draft. The difference correction module is used to correct cross-vendor configuration differences in the draft data interface configuration and convert the vendor-side configuration into the platform standard service definition, forming a unified data interface service configuration object. The matrix organization module is used to organize the unified data interface service configuration objects in the context of combined API operation, and organize the configuration content into a combined API configuration item dependency matrix. The model generation module is used to input the combined API configuration item dependency matrix into the improved xDeepFM model, generate configuration feature maps by the compressed interaction network CIN and compress the configuration outer product tensor, and output the data interface service definition result. The test and release module is used to perform interface sample tests and release flow verification on the data interface service definition results to form a publishable data interface service. The runtime governance module is used to connect publishable data interface services to the interface runtime governance link and reuse the data interface service definition results when the supplier interface changes, forming a runnable data interface service.

Images