Intelligent interface registration and framework calling method for large model

Abstract

The invention relates to the technical field of computer software, and discloses a large-model-oriented intelligent interface registration and framework calling method, which comprises the following steps that: a front-end service registers various back-end services based on a vyes framework through a uniform interface, and each back-end service transmits interface capability information through a standardized ap i. Json file; when a user requests, the front end packages request content and an ap i. Json file and submits the request content and the ap i. Json file to the large language model, the model analyzes an intention and matches an AP I interface, and a calling instruction is generated; after front-end analysis, the HTTP request is converted into a standard HTTP request to call back-end service, a back-end return result is integrated by the front end and then submitted to the large language model again to generate a natural language response, the natural language response is finally displayed to a user, and a closed-loop process is completed. According to the method, through deep fusion of self-registration, intelligent matching and automatic calling, the technical threshold of enterprise-level application is reduced, and deep landing of a large language model in the vertical field needing dynamic interaction and multi-service collaboration is promoted.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and more specifically, to a method for registering intelligent interfaces and invoking frameworks for large models. Background Technology

[0002] Large language models have shown significant application potential in multiple fields such as machine translation and intelligent customer service due to their powerful natural language processing capabilities. However, they are limited by the time domain range of the training data, making it difficult to dynamically acquire the latest external data or real-time information in specific fields. This restricts their practicality in scenarios that require real-time data interaction, such as financial market analysis.

[0003] Meanwhile, traditional API call methods rely on manual configuration. Developers need to adapt to the protocol specifications of different backend services one by one, and also need to deal with complex issues such as protocol conversion. Furthermore, the differentiated authentication mechanisms of different backend services increase the complexity of integration.

[0004] Although existing technologies attempt to optimize service call processes through tools such as API gateways, traditional API gateways are based on static routing rules, lack adaptability to dynamic business needs, and have not solved the semantic alignment problem between large language models and backend services. Natural language requests generated by large language models need to be matched with specific interfaces by manually defined rule templates, relying on preset keyword mappings or regular expressions, which limits the system's ability to parse complex intents and makes it difficult to expand.

[0005] In practical applications, these problems are particularly prominent. For example, in intelligent customer service scenarios, users’ complex requests require manual decomposition of semantics and calling backend interfaces. While large language models can understand semantics, they lack a mechanism for autonomously selecting interfaces. Existing model context protocols also suffer from wasted computing resources and response delays due to cumbersome context passing and state synchronization, making it difficult to meet real-time requirements.

[0006] Therefore, there is an urgent need for an intelligent interface registration and framework invocation method for large models to solve the contradiction between dynamic data acquisition, complex interface invocation, and semantic understanding and interface matching efficiency in the deep integration of large language models and backend services. Summary of the Invention

[0007] In view of this, the present invention proposes an intelligent interface registration and framework invocation method for large models, aiming to solve the problem of contradiction between dynamic data acquisition, complex interface invocation, and semantic understanding and interface matching efficiency in the deep integration of large language models and backend services.

[0008] This invention proposes a method for intelligent interface registration and framework invocation for large models, including:

[0009] Obtain the Vyes framework. The front-end service registers the back-end service built on the Vyes framework through a unified interface. The back-end service consists of multiple service types, supporting different entities to build their own service frameworks according to the same specification. The multiple service types include back-end service A, back-end service B, and back-end service C.

[0010] Each backend service transmits interface capability information to the frontend service through a standardized api.json file. The api.json file describes the API functions of the backend service in a structured data format. The described API functions of the backend service include interface path, HTTP method, request parameters, response structure, error handling strategy, tag classification, authentication method, permission scope and version control strategy, forming the contract basis for the interaction between the frontend and backend.

[0011] When a user makes a request to the front-end service, the front-end service packages the user's request content and the api.json file of the back-end service it depends on, and submits it to the large language model. The model determines to use the search() interface of back-end service A, the delete() interface of service B, and the add() interface of service C. Based on the Vyes framework, it automatically constructs structured prompt words to guide the large language model to parse the user's intent and traverse the interface definition, match the relevant API interfaces, generate the call URL and parameter configuration, and then return it.

[0012] The front-end service parses the information returned by the large language model, converts the information into a standard HTTP request format, and initiates a call to the corresponding back-end service;

[0013] After executing the business logic, the backend service returns a structured response result, which includes the execution status code, response data, and any existing error information.

[0014] The front-end service integrates multi-source response data, which, together with the original user request, is submitted to the large language model for comprehensive analysis and semantic fusion. The large language model generates the final response in natural language form based on the user's initial intent and the back-end return results.

[0015] The front-end service will then display the final response to the user, completing the closed-loop process from request to feedback.

[0016] Furthermore, after the front-end service displays the final response to the user and completes the closed-loop process from request to feedback, it also includes: after completing the closed-loop processing of the user request, obtaining the interface call records of each back-end service based on the log system, the call records including call frequency, response time, and error rate, and determining the interface performance level of each back-end service based on the call records;

[0017] The tag classification system of the ap i.json file is dynamically optimized based on the interface performance level.

[0018] A preset standard performance level is defined. When the interface performance level is greater than or equal to the standard performance level, the interface performance level is classified as the first performance level.

[0019] When the interface performance level is lower than the standard performance level, the interface performance level is classified as the second performance level;

[0020] Among them, interfaces of the first performance level are preferentially aggregated into the high-frequency call tag group, and interfaces of the second performance level are added with the "to be optimized" tag;

[0021] At the same time, the interface matching weight of the large language model is adjusted according to the interface performance level, and the interface with the first performance level gets high priority when matching.

[0022] Furthermore, when adjusting the interface matching weight of the large language model according to the interface performance level, the following steps are taken: obtaining the historical matching success rate and average response time of each interface based on the log system, and setting the standard success rate and standard response time.

[0023] By comparing historical matching success rates with standard success rates and average response times with standard response times, the matching performance level of the interface can be determined.

[0024] When the historical matching success rate is greater than or equal to the standard success rate and the average response time is less than or equal to the standard response time, it is judged as the first performance level;

[0025] When the historical matching success rate is greater than or equal to the standard success rate and the average response time is greater than the standard response time, it is judged as the second performance level;

[0026] When the historical matching success rate is less than the standard success rate and the average response time is greater than or equal to the standard response time, it is judged as the third performance level.

[0027] When the historical matching success rate is less than the standard success rate and the average response time is greater than the standard response time, it is judged as the fourth performance level.

[0028] Among them, the matching weights of the first to fourth performance levels decrease sequentially, and the weight of the first performance level is three times that of the fourth performance level.

[0029] Furthermore, the dynamic optimization of the tag classification system of the api.json file based on the interface performance level includes: setting a preset tag update cycle, and re-evaluating the interface performance level every time the cycle is completed;

[0030] When an interface maintains the first performance level for three consecutive cycles, it will be upgraded from the "high-frequency call tag group" to the "core interface tag group".

[0031] When the interface maintains the second performance level for two consecutive cycles, a developer alert is triggered, and interface optimization suggestions are pushed. The interface optimization suggestions include parameter simplification and caching strategy adjustment.

[0032] The optimized interface performance level needs to be verified again over a cycle, and the "to be optimized" label can only be removed after it meets the standard.

[0033] Furthermore, when the front-end service packages and submits the user request content and the dependent back-end service api.json file to the large language model, it includes: prioritizing the api.json file according to the tag classification system and matching weight of the interface;

[0034] A first weight threshold and a second weight threshold are preset, with the first weight threshold being greater than the second weight threshold:

[0035] Interface description files with matching weights greater than or equal to the first weight threshold are packaged first.

[0036] Interface description files with matching weights less than the second weight threshold will not be packaged for the time being, and will only be submitted when the large language model fails to match for the first time.

[0037] The packaged file also includes auxiliary information such as the historical success rate of API calls and the distribution of error codes.

[0038] Furthermore, the large language model parses user intent and traverses interface definitions to match relevant API interfaces, including: the large language model semantically groups user requests and extracts core operation words and parameter entities;

[0039] Based on the tag classification in the api.json file, first match the tag group that matches the core operation words, and then iterate through the parameter format of the interface in the group for secondary filtering;

[0040] A preset matching confidence threshold is set. When the confidence of the highest confidence interface is greater than or equal to the matching confidence threshold, the interface is returned directly.

[0041] When the confidence level is less than the threshold, the top three high-confidence interfaces are returned for secondary verification by the front-end service.

[0042] Furthermore, when the front-end service performs secondary verification on the interface returned by the large language model, it includes: verifying whether the permission scope of the interface matches the user role;

[0043] Verify that the required fields of the request parameters are complete and that the format conforms to the api.json definition;

[0044] If the verification passes, the API call will be executed.

[0045] When verification fails, the error message is sent to the large language model, requesting that the calling instruction be regenerated.

[0046] Furthermore, after the backend service returns a structured response result, when the frontend service integrates the multi-source response data, it includes: marking the response results in time sequence according to the interface call order, and extracting the status codes from each result, wherein the status code 400 indicates an error in the request parameters, 401 indicates unauthorized access, and 500 indicates a server-side error.

[0047] When there are conflicts between multiple data sources, the result of the interface with the highest performance level shall be adopted first according to the interface performance level.

[0048] The structured data is standardized to form a fusion dataset that can be directly analyzed by large language models.

[0049] Furthermore, when the large language model generates natural language responses based on the fused dataset, it includes: adjusting the level of detail in the response according to the urgency of the user's request.

[0050] When a user request is urgent, only the core result is returned; when a user request is non-urgent, additional processing instructions are provided.

[0051] The response also includes data source identification for easy traceability.

[0052] Furthermore, in the entire interface call process, the handling of abnormal situations includes: setting a preset interface call timeout threshold; when the interface call time exceeds the interface call timeout threshold, automatically retrying twice; if it still fails, switching to a backup interface.

[0053] When a 401 Unauthorized Error occurs three times in a row, the identity re-authentication process is triggered, requiring the user to provide a new token.

[0054] All exception information is recorded in the logging system for dynamic evaluation of interface performance levels;

[0055] The exception information includes the error code, timestamp, and interface name.

[0056] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0057] By using the unified registration and standardized api.json file interface description of the backend service based on the Vyes framework, dynamic management and unified contract of interface capabilities are realized, avoiding the high time consumption and error-prone problems of traditional manual configuration, and improving the discoverability and maintainability of the interface.

[0058] Leveraging the semantic parsing and intelligent matching capabilities of large language models, it automatically parses users' complex intents and accurately matches them with interfaces, without relying on preset keyword mappings. This improves the efficiency of processing complex intents and solves the problem of the disconnect between semantic understanding and interface call efficiency.

[0059] The automated process of front-end and back-end collaboration reduces manual intervention, lowers the cost of cross-service integration and response latency, while the framework's built-in error handling and security policies ensure the reliability and security of calls. The dynamic data acquisition capability breaks through the time domain limitations of large model training data, expanding its practical value in scenarios such as financial analysis and intelligent customer service. Attached Figure Description

[0060] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0061] Figure 1 The first flowchart of the intelligent interface registration and framework invocation method for large models provided in the embodiments of the present invention;

[0062] Figure 2 The second flowchart of the intelligent interface registration and framework invocation method for large models provided in the embodiments of the present invention;

[0063] Figure 3 A flowchart for intelligent front-end interface invocation provided by this invention;

[0064] Figure 4 The flowchart for front-end multi-source information integration provided by this invention. Detailed Implementation

[0065] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, embodiments and features in the embodiments of the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0066] Reference Figure 1-4 As shown in some embodiments of this application, a method for registering intelligent interfaces and invoking frameworks for large models includes:

[0067] S100: The front-end service can easily register back-end services built on the Vyes framework through a simple and unified interface. This back-end service consists of various service types, supporting different entities to build their own service frameworks according to the same specification, enabling flexible access and unified management.

[0068] S200: Each backend service (such as backend service A, backend service B, and backend service C) transmits interface capability information to the frontend service through a standardized api.json file, forming the contractual basis for frontend-backend interaction. This file fully describes the API functions of the backend service in a structured data format, including but not limited to interface paths, supported HTTP methods (such as GET, POST, PUT, DELETE), request parameter types and formats, response data structures, error handling strategies, and other key information, ensuring that the frontend service can accurately parse and call the corresponding interfaces. For example, in a user management scenario, the backend service can define a GET method under the " / users" path to retrieve the user list, a POST method to create users, a PUT method to update user information, and a DELETE method to delete users, and specify the request body content through parameter validation rules (such as required fields and data format constraints). To enhance the discoverability and maintainability of APIs, api.json employs a tag-based classification system to semantically group functions. For example, the "Users" tag aggregates user management-related operations, the "Authentication" tag covers authentication interfaces, and the "Data" tag associates data processing functions. This provides efficient API retrieval and invocation support for front-end services and intelligent systems (such as large language models). Furthermore, api.json includes a detailed error handling mechanism. Standardized HTTP status codes (e.g., 400 for incorrect request parameters, 401 for unauthorized access, and 500 for server-side errors) and structured error information (e.g., error type, specific cause, and suggested fixes) help front-end services quickly locate and handle exceptions. Regarding security, the file explicitly declares authentication methods (e.g., OAuth 2.0, JWT) and permission scopes (e.g., "read:users" only allows reading user data, "write:users" allows modifying user information), and requires request headers to carry access tokens via the BearerToken pattern to ensure the security of API calls. To accommodate continuous iteration, api.json supports version control strategies, such as distinguishing different versions by URL path (e.g., / v2 / users) or request header (e.g., Accept:application / vnd.example.v2+json), ensuring backward compatibility.

[0069] S300: When a user sends a request to the system's frontend service, the frontend service packages the user's specific request content along with the api.json interface description files of the various backend services it depends on, and submits this data package to the Large Language Model (LLM) integrated into the system for analysis. The specific process is as follows: Figure 3 As shown, with the help of the framework of this invention integrated in the front end, the system can automatically construct structured prompts to guide the large language model to deeply understand and semantically parse the user's request intent.

[0070] Subsequently, the large language model will, based on the user's actual needs, traverse and retrieve the api.json files provided by each backend service, identifying the most matching API interface service. For example... Figure 1 As shown, assuming a user request requires three operations: "search," "delete," and "add," the large language model will search for the corresponding APIs in the interface definitions of different backend services. Ultimately, the model determines to use the search() interface of backend service A, the delete() interface of service B, and the add() interface of service C.

[0071] Based on this, the large language model combines the detailed description information (including parameter format, request method, path, etc.) provided by these three interfaces in api.json with the specific input information in the user's original request to generate the corresponding API call URL and parameter configuration, and returns the complete call instruction to the front-end service, thereby realizing an intelligent and automatic service interface selection and call process.

[0072] S400: After receiving the interface call selection information returned by the large language model, the front-end service, with the help of the framework of this invention integrated into the front-end, can efficiently parse and process the returned content. The system framework automatically extracts the interface information recommended by the large language model, including the target backend service address, the specific calling method, and the required parameters, and converts it into a standard HTTP request format.

[0073] Subsequently, based on the parsed results, the front-end service sends requests to the corresponding back-end service, precisely invoking the required interfaces. This process not only improves the efficiency of front-end and back-end interaction but also enables automatic service scheduling and integration based on semantic understanding, significantly reducing the manual configuration and debugging costs required for connecting multiple back-end interfaces in traditional development models. Simultaneously, the entire process possesses excellent scalability and fault tolerance, adapting to back-end service interfaces with different structures and sources, ensuring system stability and response speed.

[0074] S500: After receiving the call instruction from the frontend service, the backend service will execute the corresponding business logic according to the request content and return a structured response result to the frontend service. This feedback information typically includes the execution status code, response data, and possible error messages to ensure that the frontend can accurately understand the result of the backend processing.

[0075] S600: After receiving the response results from all backend services, the frontend service, using the integrated framework of this invention, performs unified integration and structured processing of the returned data from different backend interfaces. Subsequently, the frontend service encapsulates the processed multi-source response information along with the original user request content and submits it again to the Large Language Model (LLM) in the system for comprehensive analysis and semantic fusion. For example... Figure 4 As shown.

[0076] The large language model performs deep semantic understanding and logical reasoning based on the user's initial request intent and the actual return results from each backend service, thereby generating a final response in natural language form that meets the user's needs. This response not only accurately reflects the business processing results, but can also generate summaries, explanations, or suggestions based on the actual scenario to improve user experience and interactivity.

[0077] S700: The front-end service will display the final answer to the user, thus completing a closed-loop process from user request to intelligent processing and result feedback.

[0078] The above embodiments achieve dynamic management and unified contracts for interface capabilities through unified registration and standardized api.json file interface descriptions based on the Vyes framework in the backend service. This avoids the high time consumption and error-proneness of traditional manual configuration, and improves the discoverability and maintainability of interfaces. By leveraging the semantic parsing and intelligent matching capabilities of large language models, it automatically parses user complex intents and accurately matches interfaces without relying on preset keyword mapping, improving the efficiency of complex intent processing and solving the problem of the disconnect between semantic understanding and interface call efficiency. The automated process of front-end and back-end collaboration reduces manual intervention, lowers cross-service integration costs and response latency, while the framework's built-in error handling and security policies ensure the reliability and security of calls. The dynamic data acquisition capability breaks through the time domain limitations of large model training data, expanding its practical value in scenarios such as financial analysis and intelligent customer service.

[0079] Specifically, after the front-end service displays the final response to the user and completes the closed-loop process from request to feedback, it also includes: after completing the closed-loop processing of the user request, obtaining the interface call records of each back-end service based on the log system. The call records include call frequency, response time, and error rate. The interface performance level of each back-end service is determined based on the call records.

[0080] The tag classification system in the api.json file is dynamically optimized based on the interface performance level:

[0081] A preset standard performance level is defined. When the interface performance level is greater than or equal to the standard performance level, the interface performance level is classified as the first performance level.

[0082] When the interface performance level is lower than the standard performance level, the interface performance level is classified as the second performance level;

[0083] Among them, interfaces of the first performance level are preferentially aggregated into the high-frequency call tag group, and interfaces of the second performance level are added with the "to be optimized" tag;

[0084] At the same time, the interface matching weight of the large language model is adjusted according to the interface performance level, and the interface with the first performance level gets high priority when matching.

[0085] Specifically, when the large language model traverses the interface definitions, it prioritizes searching for interfaces with higher weight values. When there are multiple candidate interfaces, they are sorted by weight from high to low before the matching degree is calculated, which further improves the efficiency and accuracy of interface matching.

[0086] In addition, the logging system generates weekly interface performance analysis reports, recording data such as the ratio of interfaces in the first and second performance levels, and the impact of weight adjustments on matching success rates. This provides a basis for subsequent optimization of the tag classification system and adjustment of weight coefficients. When an interface remains in the second performance level for four consecutive weeks, a developer alert is automatically triggered, prompting targeted optimization of the interface performance.

[0087] The above embodiments achieve dynamic optimization of the api.json tag classification system and targeted adjustment of the interface matching weight of the large language model by obtaining interface call records based on the log system after the closed-loop process and classifying them into performance levels. Among them, interfaces of the first performance level are preferentially aggregated into the high-frequency call tag group and given higher matching weights, while interfaces of the second performance level are marked as "to be optimized". This mechanism not only allows the large language model to more efficiently prioritize matching interfaces with better performance, improving the response speed and success rate of user requests, but also guides resources to be tilted towards high-frequency and high-quality interfaces through dynamic adjustment of tags and weight tilting. At the same time, the "to be optimized" tag is used to accurately locate interfaces that need improvement, and combined with log data, it provides developers with clear optimization directions, continuously iterating to improve the overall service quality and system operating efficiency, forming a virtuous cycle of "call feedback - performance evaluation - dynamic optimization", and further strengthening the framework's adaptability and intelligence.

[0088] Specifically, when adjusting the interface matching weight of the large language model according to the interface performance level, the following steps are taken: obtaining the historical matching success rate and average response time of each interface based on the log system, and setting the standard success rate and standard response time.

[0089] By comparing historical matching success rates with standard success rates and average response times with standard response times, the matching performance level of the interface can be determined.

[0090] When the historical matching success rate is greater than or equal to the standard success rate and the average response time is less than or equal to the standard response time, it is judged as the first performance level;

[0091] When the historical matching success rate is greater than or equal to the standard success rate and the average response time is greater than the standard response time, it is judged as the second performance level;

[0092] When the historical matching success rate is less than the standard success rate and the average response time is greater than or equal to the standard response time, it is judged as the third performance level.

[0093] When the historical matching success rate is less than the standard success rate and the average response time is greater than the standard response time, it is judged as the fourth performance level.

[0094] Among them, the matching weights of the first to fourth performance levels decrease sequentially, and the weight of the first performance level is three times that of the fourth performance level.

[0095] The above embodiments divide performance levels by combining historical matching success rate and average response time as dual-dimensional indicators, and assign matching weights that decrease sequentially from the first to the fourth performance level (the weight of the first performance level is three times that of the fourth). This allows the large language model to prioritize high-quality interfaces with high success rates and fast responses when matching interfaces, reducing the probability of mismatches with inefficient interfaces. This not only improves the accuracy and efficiency of interface calls, but also guides system resources to tilt towards high-performance interfaces through quantified weight differences, further optimizing the overall service response speed and user experience.

[0096] Specifically, the tag classification system of the api.json file is dynamically optimized based on the interface performance level, including: a preset tag update cycle, and a reassessment of the interface performance level every time the cycle is completed;

[0097] When an interface maintains the first performance level for three consecutive cycles, it will be upgraded from the "high-frequency call tag group" to the "core interface tag group".

[0098] When the interface maintains the second performance level for two consecutive cycles, a developer alert is triggered, and interface optimization suggestions are pushed. The interface optimization suggestions include parameter simplification and caching strategy adjustment.

[0099] The optimized interface performance level needs to be verified again over a cycle, and the "to be optimized" label can only be removed after it meets the standard.

[0100] The above embodiments periodically review interface performance by setting a fixed tag update cycle. For interfaces that maintain a high level of performance for three consecutive cycles, the first-level interfaces are promoted from the "high-frequency call tag group" to the "core interface tag group," strengthening their priority and resource allocation in interface matching. For interfaces that are in the second-level performance for two consecutive cycles, developer alerts are triggered in real time, and targeted optimization suggestions such as parameter simplification and caching strategy adjustment are pushed to force interface performance improvement. Optimized interfaces must undergo a full cycle of verification before the "to be optimized" tag can be removed. This forms a closed-loop management mechanism of "evaluation-grading-optimization-verification," which not only ensures the stability and calling efficiency of core interfaces but also achieves refined management of interface resources through dynamic tag adjustments. This improves the timeliness and practicality of the api.json file tag system, laying the foundation for efficient interface matching of large language models.

[0101] Specifically, when the front-end service packages and submits the user request content and the dependent back-end service api.json file to the large language model, it includes: prioritizing the api.json file according to the interface's tag classification system and matching weight;

[0102] A first weight threshold and a second weight threshold are preset, with the first weight threshold being greater than the second weight threshold:

[0103] Interface description files with matching weights greater than or equal to the first weight threshold are packaged first.

[0104] Interface description files with matching weights less than the second weight threshold will not be packaged for the time being, and will only be submitted when the large language model fails to match for the first time.

[0105] The packaged file also includes auxiliary information such as the historical success rate of API calls and the distribution of error codes.

[0106] Specifically, when the front-end service submits user requests and the back-end service api.json file to the large language model, priority is ranked by combining the interface tag classification system and matching weight. High-value interfaces with matching weight greater than or equal to the first weight threshold are packaged first, while low-priority interfaces with matching weight less than the second weight threshold are temporarily stored and submitted only when the large language model fails to match on the first attempt. Auxiliary information such as the historical success rate of interface calls and error code distribution are attached to the packaged file. This ensures that the large language model can focus on core interface resources during the initial matching, improving matching efficiency. At the same time, the layered submission mechanism avoids interference from redundant information. Furthermore, the use of historical data helps the large model to more accurately understand the characteristics and quality of interfaces, further optimizing the accuracy of intent parsing and interface matching, and achieving a balance between resource utilization and matching effect.

[0107] The above embodiments reduce the parsing burden on the large language model and accelerate the initial matching speed by prioritizing the transmission of high-weight interface information; the supplementary submission mechanism for low-weight interfaces avoids the omission of key interfaces and ensures the completeness of the matching; and the accompanying historical call data provides decision-making references for the model, improving the accuracy of interface matching. Overall, this not only optimizes the efficiency of front-end and back-end data interaction but also enhances the large language model's ability to respond to complex requests, further improving the system's intelligent processing level and user experience.

[0108] Specifically, the large language model parses user intent and traverses interface definitions to match relevant API interfaces, including: the large language model semantically groups user requests and extracts core operation words and parameter entities;

[0109] Based on the tag classification in the api.json file, first match the tag group that matches the core operation words, and then iterate through the parameter format of the interface in the group for secondary filtering;

[0110] A preset matching confidence threshold is set. When the confidence of the highest confidence interface is greater than or equal to the matching confidence threshold, the interface is returned directly.

[0111] When the confidence level is less than the threshold, the top three high-confidence interfaces are returned for secondary verification by the front-end service.

[0112] In the above embodiment, the large language model first performs semantic grouping on the user request, extracts the core operation words and parameter entities, then matches the corresponding tag group according to the tag classification of api.json, iterates through the interface parameter format within the group for secondary filtering, and combines the preset matching confidence threshold. If the highest confidence score meets the standard, the interface is returned directly; otherwise, the top three high-confidence interfaces are returned for secondary verification by the front-end service, thereby improving the accuracy and reliability of interface matching.

[0113] Specifically, when the front-end service performs secondary verification on the interface returned by the large language model, it includes: verifying whether the permission scope of the interface matches the user role;

[0114] Verify that the required fields of the request parameters are complete and that the format conforms to the api.json definition;

[0115] If the verification passes, the API call will be executed.

[0116] When verification fails, the error message is sent to the large language model, requesting that the calling instruction be regenerated.

[0117] Specifically, when the front-end service performs secondary verification on the API returned by the large language model, it first checks whether the API permission scope matches the current user role. For example, the "Modify User Information" API requires verification of whether the user has administrator privileges. Then, it checks whether the required fields defined in api.json in the request parameters are complete, such as whether the user ID and timestamp are missing, and verifies whether the parameter format conforms to the specifications, such as whether the date format is "YYYY-MM-DD" and whether the numerical parameters are within the valid range. If both verifications pass, the API call is executed directly. If the permissions do not match or the parameters are missing or incorrectly formatted, the specific error information (such as "Missing required parameter 'User ID'" or "Current role does not have modification permission") is fed back to the large language model, requiring it to regenerate a compliant API call instruction based on the error reason, ensuring the legality and accuracy of the API call and avoiding call failures due to permission issues or incorrect parameters.

[0118] The above embodiments, by performing secondary verification on the large language model's returned interface for permission matching and parameter integrity and format compliance, can effectively intercept interface calls with incorrect permissions or parameters, avoiding backend service anomalies caused by illegal calls or invalid requests, and reducing the risk of system errors. At the same time, specific error information is fed back to the large language model to regenerate instructions, forming a closed loop of "model recommendation - front-end verification - error correction", which further improves the accuracy and legality of interface calls, ensures the security and stability of system interaction, and ultimately optimizes the processing efficiency and experience of user requests.

[0119] Specifically, when the front-end service integrates multi-source response data after the back-end service returns a structured response result, it includes: marking the response results in time sequence according to the order of interface calls, extracting the status codes from each result, with status code 400 indicating incorrect request parameters, 401 indicating unauthorized access, and 500 indicating server-side exception.

[0120] When there are conflicts between multiple data sources, the result of the interface with the highest performance level shall be adopted first according to the interface performance level.

[0121] The structured data is standardized to form a fusion dataset that can be directly analyzed by large language models.

[0122] Specifically, after the backend service returns a structured response, the frontend service, when integrating multi-source response data, adds a timestamp to each response in the order of API calls for time-series marking. It also extracts the status codes from each response (e.g., 400 for incorrect request parameters, 401 for unauthorized access, and 500 for server error) to facilitate subsequent traceability and problem localization. When data returned by different backend services conflict (e.g., the same order displays "paid" in service A but "unpaid" in service B), priority is strictly determined based on API performance levels, with the highest performance API being prioritized. The results of the graded interface ensure data consistency. In addition, the response data is standardized, including unifying the date format (e.g., converting "MM / DD / YYYY" to "YYYY-MM-DD"), numerical units (e.g., unifying "kilogram" to "g"), and field naming rules (e.g., unifying "user_name" and "username" to "userName"). The final result is a standardized and logically consistent fusion dataset, providing high-quality input for the comprehensive analysis and semantic fusion of the large language model, and improving the accuracy and coherence of subsequent natural language responses.

[0123] The above embodiments, by adding timing markers and extracting status codes according to the call sequence, enable the front-end service to clearly trace the flow of multi-source responses, quickly locate abnormal interfaces (such as issues corresponding to status codes like 400 and 401), and improve troubleshooting efficiency. When data conflicts occur, the results from the higher-performing interface are prioritized based on performance level, ensuring the reliability and consistency of the fused data. Standardized processing unifies data formats and rules, providing standardized input for large language models, reducing model parsing costs, and improving the accuracy of semantic fusion. The overall mechanism strengthens the traceability and consistency of multi-source data, lays a high-quality data foundation for subsequent natural language response generation, and further optimizes the system's response efficiency and user experience.

[0124] Specifically, when large language models generate natural language responses based on fused datasets, they include: adjusting the level of detail in the response according to the urgency of the user's request.

[0125] When a user request is urgent, only the core result is returned; when a user request is non-urgent, additional processing instructions are provided.

[0126] The response also includes data source identification for easy traceability.

[0127] Specifically, when the large language model generates natural language responses based on the fused dataset, it first determines the urgency level by identifying urgency markers in the user's request (such as keywords like "immediately" and "urgent"). For urgent requests, only the core results are extracted for the response; for example, if a user asks "urgently inquire whether order 123 has been shipped," the response is "order 123 has been shipped." For non-urgent requests, a processing description is added in addition to the core results; for example, if a user asks "shipping status of order 123," the response is "order 123 was shipped from the Shanghai warehouse at 9:00 AM today and is expected to arrive in 3 days; logistics information comes from logistics service A." Simultaneously, all responses clearly indicate the data source, such as "information from inventory service B" or "data provided by payment service C," satisfying users' information needs under different levels of urgency while ensuring traceability of responses through source identification, thus increasing user trust in the results.

[0128] The above-described method of generating natural language responses can flexibly adjust the response strategy according to the urgency of the user's request. In urgent situations, it can quickly provide core results to meet immediate needs, while in non-urgent situations, it can supplement process descriptions to enhance the completeness of information. At the same time, by clearly marking the source of data, it allows users to know the source of information, which not only improves the efficiency of interaction and the practicality of information, but also ensures the traceability of the response, enhances the user's trust in the results, and further optimizes the overall service experience.

[0129] Specifically, the handling of abnormal situations in the entire interface call process includes: setting a preset interface call timeout threshold; when the interface call time exceeds the interface call timeout threshold, automatically retrying twice; if it still fails, switching to a backup interface.

[0130] When a 401 Unauthorized Error occurs three times in a row, the identity re-authentication process is triggered, requiring the user to provide a new token.

[0131] All exception information is recorded in the logging system for dynamic evaluation of interface performance levels;

[0132] The error message includes the error code, timestamp, and interface name.

[0133] Specifically, the handling of exceptions in the entire API call process is as follows: First, a clear API call timeout threshold is set. When an API call takes longer than this threshold, the system automatically initiates a retry mechanism, retrying twice consecutively to rule out temporary issues such as instantaneous network fluctuations. If the call still fails after two retries, it immediately switches to a pre-configured backup API (e.g., if the query API of service A times out, the backup query API of service D is automatically called) to ensure business continuity. When the API returns a 401 Unauthorized error three times consecutively, the system determines that the current user's authentication information is invalid and triggers a re-authentication process. The system guides the user to supplement or update their access token through front-end pop-ups or message prompts, ensuring the security and compliance of the API call. Meanwhile, all abnormal situations (including timeout errors, 401 errors, and others such as 500 server errors) will be recorded in detail in the logging system. Each record contains the specific error code (e.g., 408 indicates timeout, 401 indicates unauthorized), the exact timestamp of the error, the name of the interface involved, and other key information. This data will serve as an important basis for subsequent evaluation of interface performance levels and optimization of interface quality, forming a complete closed loop of "anomaly capture - automatic processing - log feedback - performance optimization" to improve the stability, fault tolerance, and maintainability of the system.

[0134] The above embodiments effectively reduce the impact of momentary failures on service continuity and improve the system's resilience by automatically retrying after timeouts and switching to backup interfaces. Consecutive 401 errors triggering re-authentication strengthens the security of interface calls and the rigor of access control. Complete logging of exception information provides accurate data support for interface performance evaluation and optimization, facilitating continuous iteration and upgrades. Overall, a closed-loop "prevention-processing-feedback" exception management system is formed, ensuring stable processing of user requests, enhancing system reliability, security, and maintainability, and further optimizing the service experience.

[0135] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program goods. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program goods embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0136] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program goods according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0137] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0138] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0139] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for intelligent interface registration and framework invocation for large models, characterized in that, include: Obtain the Vyes framework. The front-end service registers the back-end service built on the Vyes framework through a unified interface. The back-end service consists of multiple service types, supporting different entities to build their own service frameworks according to the same specification. The multiple service types include back-end service A, back-end service B, and back-end service C. Each backend service transmits interface capability information to the frontend service through a standardized api.json file. The api.json file describes the API functions of the backend service in a structured data format. The described API functions of the backend service include interface path, HTTP method, request parameters, response structure, error handling strategy, tag classification, authentication method, permission scope and version control strategy, forming the contract basis for the interaction between the frontend and backend. When a user makes a request to the front-end service, the front-end service packages the user's request content and the api.json file of the back-end service it depends on, submits it to the large language model, automatically constructs structured prompt words based on the Vyes framework, guides the large language model to parse the user's intent and traverse the interface definition, match the relevant API interface, generate the call URL and parameter configuration and return it. The front-end service parses the information returned by the large language model, converts the information into a standard HTTP request format, and initiates a call to the corresponding back-end service; After executing the business logic, the backend service returns a structured response result, which includes the execution status code, response data, and any existing error information. The front-end service integrates multi-source response data, which, together with the original user request, is submitted to the large language model for comprehensive analysis and semantic fusion. The large language model generates the final response in natural language form based on the user's initial intent and the back-end return results. The front-end service will then display the final response to the user, completing the closed-loop process from request to feedback.

2. The intelligent interface registration and framework invocation method for large models according to claim 1, characterized in that, After the front-end service displays the final response to the user, completing the closed loop from request to feedback, it also includes: After completing the closed-loop processing of user requests, the interface call records of each backend service are obtained based on the log system. The call records include call frequency, response time, and error rate. The interface performance level of each backend service is determined based on the call records. The tag classification system of the ap i.json file is dynamically optimized based on the interface performance level. A preset standard performance level is defined. When the interface performance level is greater than or equal to the standard performance level, the interface performance level is classified as the first performance level. When the interface performance level is lower than the standard performance level, the interface performance level is classified as the second performance level; Among them, interfaces of the first performance level are preferentially aggregated into the high-frequency call tag group, and interfaces of the second performance level are added with the "to be optimized" tag; At the same time, the interface matching weight of the large language model is adjusted according to the interface performance level, and the interface with the first performance level gets high priority when matching.

3. The intelligent interface registration and framework invocation method for large models according to claim 2, characterized in that, When adjusting the interface matching weights of a large language model based on interface performance levels, the following should be included: Based on the log system, the historical matching success rate and average response time of each interface are obtained, and the standard success rate and standard response time are preset. By comparing historical matching success rates with standard success rates and average response times with standard response times, the matching performance level of the interface can be determined. When the historical matching success rate is greater than or equal to the standard success rate and the average response time is less than or equal to the standard response time, it is judged as the first performance level; When the historical matching success rate is greater than or equal to the standard success rate and the average response time is greater than the standard response time, it is judged as the second performance level; When the historical matching success rate is less than the standard success rate and the average response time is greater than or equal to the standard response time, it is judged as the third performance level. When the historical matching success rate is less than the standard success rate and the average response time is greater than the standard response time, it is judged as the fourth performance level. Among them, the matching weights of the first to fourth performance levels decrease sequentially, and the weight of the first performance level is three times that of the fourth performance level.

4. The intelligent interface registration and framework invocation method for large models according to claim 3, characterized in that, The dynamic optimization of the tag classification system in the api.json file based on the interface performance level includes: A preset tag update cycle is set, and the interface performance level is re-evaluated every time this cycle is completed. When an interface maintains the first performance level for three consecutive cycles, it will be upgraded from the "high-frequency call tag group" to the "core interface tag group". When the interface maintains the second performance level for two consecutive cycles, a developer alert is triggered, and interface optimization suggestions are pushed. The interface optimization suggestions include parameter simplification and caching strategy adjustment. The optimized interface performance level needs to be verified again over a cycle, and the "to be optimized" label can only be removed after it meets the standards.

5. The intelligent interface registration and framework invocation method for large models according to claim 4, characterized in that, When the frontend service packages the user request content and the dependent backend service api.json file and submits it to the large language model, it includes: The api.json file is prioritized based on the tag classification system and matching weight of the interface. A first weight threshold and a second weight threshold are preset, with the first weight threshold being greater than the second weight threshold: Interface description files with matching weights greater than or equal to the first weight threshold are packaged first. Interface description files with matching weights less than the second weight threshold will not be packaged for the time being, and will only be submitted when the large language model fails to match for the first time. The packaged file also includes auxiliary information such as the historical success rate of API calls and the distribution of error codes.

6. The intelligent interface registration and framework invocation method for large models according to claim 5, characterized in that, The large language model parses user intent and iterates through interface definitions to match relevant API interfaces, including: The large language model semantically groups user requests and extracts core operation words and parameter entities; Based on the tag classification in the api.json file, first match the tag group that matches the core operation words, and then iterate through the parameter format of the interface in the group for secondary filtering; A preset matching confidence threshold is set. When the confidence of the highest confidence interface is greater than or equal to the matching confidence threshold, the interface is returned directly. When the confidence level is less than the threshold, the top three high-confidence interfaces are returned for secondary verification by the front-end service.

7. The intelligent interface registration and framework invocation method for large models according to claim 6, characterized in that, When the front-end service performs secondary validation on the API returned by the large language model, it includes: Verify whether the permission scope of the verification interface matches the user's role; Verify that the required fields of the request parameters are complete and that the format conforms to the api.json definition; If the verification passes, the API call will be executed. When verification fails, the error message is sent to the large language model, requesting that the calling instruction be regenerated.

8. The intelligent interface registration and framework invocation method for large models according to claim 7, characterized in that, After the backend service returns a structured response, the frontend service integrates the multi-source response data, including: The response results are time-stamped according to the order of interface calls, and the status codes of each result are extracted. The status code 400 indicates an error in the request parameters, 401 indicates unauthorized access, and 500 indicates a server-side error. When there are conflicts between multiple data sources, the result of the interface with the highest performance level shall be adopted first according to the interface performance level. The structured data is standardized to form a fusion dataset that can be directly analyzed by large language models.

9. The intelligent interface registration and framework invocation method for large models according to claim 8, characterized in that, When large language models generate natural language responses based on fused datasets, they include: Adjust the level of detail in the response based on the urgency of the user's request: When a user request is urgent, only the core result is returned; when a user request is non-urgent, additional processing instructions are provided. The response also includes data source identification for easy traceability.

10. The intelligent interface registration and framework invocation method for large models according to claim 9, characterized in that, The handling of exceptions throughout the entire API call process includes: A preset timeout threshold for API calls is set. If the API call timeout exceeds the timeout threshold, the API will automatically retry twice. If it still fails, the API will switch to a backup API. When a 401 Unauthorized Error occurs three times in a row, the identity re-authentication process is triggered, requiring the user to provide a new token. All exception information is recorded in the logging system for dynamic evaluation of interface performance levels; The exception information includes the error code, timestamp, and interface name.

Images