Interface index, index tree construction methods, electronic devices and program products

Abstract

This disclosure provides an interface index, an index tree construction method, an electronic device, and a program product. The method includes: responding to an interface index request by parsing the interface index request; and based on the parsing result, searching for a target interface through an index tree. The index tree construction method includes: generating scene description text for the interface based on its structured metadata; vectorizing the scene description text to obtain a semantic vector; and vectorizing the structured metadata to obtain a structure vector; and merging different interfaces based on their semantic and structure vectors to generate an index tree containing scene relationships between the different interfaces.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to interface indexes, index tree building methods, electronic devices, and program products. Background Technology

[0002] During software development, developers need to look up the meaning of interfaces through interface documentation (i.e., API documentation).

[0003] In existing query solutions, some complex business scenarios involve multiple interfaces and various business scenarios, but the interface documentation often lacks sufficient explanation. In many cases, although interface names are similar, their call parameters, calling rules, or applicable business scenarios differ. This makes it difficult for developers to quickly find the correct interface when querying. Therefore, a solution is needed to improve the accuracy of interface indexing. Summary of the Invention

[0004] This disclosure provides interface indexes, index tree construction methods, electronic devices, and program products.

[0005] According to a first aspect of this disclosure, an interface indexing method is provided. The method specifically includes: parsing an interface indexing request in response to such a request; searching for a target interface using an index tree based on the parsing result; wherein the index tree is constructed by: generating a scene description text for the interface based on its structured metadata; vectorizing the scene description text to obtain a semantic vector; and vectorizing the structured metadata to obtain a structure vector; and merging different interfaces based on their semantic and structure vectors to generate an index tree containing scene relationships between the different interfaces.

[0006] According to the above solution, by expanding business semantics, the system can understand high-level business concepts rather than just matching literal keywords, thus solving the problem of poor semantic understanding. Furthermore, merging semantic vectors and structural vectors preserves the inherent scenario hierarchy of the API interface while establishing business semantic relationships, avoiding the structural information destruction problem in general vector retrieval. During the query process, a scenario relationship index tree is used to support multi-level retrieval from high-level business intent to low-level interface parameters, enabling users to quickly locate the required interface using natural business language, improving interface query efficiency and accuracy.

[0007] According to at least one embodiment of this disclosure, in response to an interface index request, the interface index request is parsed; based on the parsing result, the target interface is searched through an index tree, including: parsing the interface index request to obtain parameter information and scene information; searching for a first candidate interface from the interface database based on the parameter information; traversing the index tree to the second candidate interface and the scene summary in the corresponding parent node based on the scene information; if the first candidate interface and the second candidate interface are the same, then the second candidate interface is taken as the target interface.

[0008] According to the above solution, by simultaneously analyzing parameter information and scenario information, both technical accuracy and business semantic understanding are taken into account, thus solving the problem of incomplete coverage by a single search mode. Furthermore, the first and second alternative interfaces jointly select the target interface, effectively improving the accuracy of search results.

[0009] According to at least one embodiment of this disclosure, the scene description text is vectorized to obtain a semantic vector; and the structured metadata is vectorized to obtain a structure vector, including: inputting the scene description text into a first model to extract semantic features; vectorizing the semantic features to obtain a semantic vector corresponding to the interface; and inputting the structured metadata into a second model to obtain structural features representing the business relationships of the metadata; vectorizing the structural features to obtain a structure vector corresponding to the interface.

[0010] According to the above scheme, by extracting semantic vectors representing the business semantic feature space of API interfaces, the retrieval system can identify the semantic relationships between different levels of business scenarios; by extracting structural vectors representing the topological relationships of API interfaces in the technical architecture, it ensures that the retrieval results conform to the structural constraints of the system design. These two vector representation mechanisms enable API retrieval to have both the flexibility of semantic understanding and the accuracy of technical architecture constraints, effectively solving the technical problems of insufficient semantic understanding capabilities and destruction of structural information.

[0011] According to at least one embodiment of this disclosure, generating scene description text for an interface based on structured metadata of the interface includes: constructing scene generation prompts using the structured metadata of the interface and scene description information; and inputting the scene generation prompts into a large model to generate scene description text for the interface.

[0012] According to the above solution, by utilizing a large model to generate scenario description text, the problem of missing business semantics in existing API documentation is solved, enabling each interface to have a complete business context description. Furthermore, a unified prompt word template ensures the professionalism and consistency of the generated content, eliminating document quality differences caused by manual writing. The generated scenario description text accurately captures the interface's location and association within the business process, providing a foundation for subsequent semantic and structural retrieval.

[0013] According to at least one embodiment of this disclosure, different interfaces are merged based on semantic vectors and structural vectors to generate an index tree containing scene relationships of different interfaces. The process includes: calculating a first similarity between any two interfaces among multiple different interfaces based on semantic vectors; calculating a second similarity between any two interfaces among multiple different interfaces based on structural vectors; calculating a comprehensive similarity between two interfaces using the first and second similarities; recursively searching for two interfaces to be merged that have the largest comprehensive similarity and a second similarity greater than a similarity threshold; and merging the two interfaces to be merged to generate an index tree containing scene relationships of different interfaces.

[0014] According to the above scheme, the second similarity threshold constraint mechanism ensures that the index tree retains the technical architecture relationship between nodes (i.e., the scenario relationship of interfaces), preventing semantically similar but architecturally unrelated interfaces from being incorrectly clustered. Furthermore, the comprehensive similarity calculation method integrates business semantics and technical architecture features, maintaining the flexibility of semantic retrieval while ensuring the rigor of technical constraints, thus enabling the index tree to possess both business semantic and technical architecture layers.

[0015] According to at least one embodiment of this disclosure, merging two interfaces to be merged to generate an index tree containing scene relationships of different interfaces includes: after merging all interfaces, treating all interfaces as leaf nodes and scene levels as parent nodes; calculating scene summaries of parent nodes using a large model; and constructing an index tree containing scene relationships of different interfaces based on leaf nodes and parent nodes containing scene summaries.

[0016] According to the above scheme, the connection relationships between nodes in the tree structure fully preserve the business scenario hierarchy and relevance of the API interfaces, enabling users to intuitively understand the positioning and interrelationships of the interfaces in the business process. Furthermore, the scenario summary of the parent node provides a clear semantic explanation for each business abstraction level, making implicit business relationships explicit and avoiding the problem of missing business semantics in the API documentation.

[0017] According to at least one embodiment of this disclosure, in response to an interface index request, the interface index request is parsed; based on the parsing result, the target interface is searched through an index tree, including: in response to the interface index request, determining the query type of the interface index request; if the query type is an exact query, the target interface is searched from the interface database according to the parameter information carried in the interface index request; if the query type is a semantic query, the scene summary is traversed to the target interface and the corresponding parent node based on the index tree.

[0018] According to the above scheme, an automatic query type identification mechanism is used to adopt the optimal retrieval strategy for query requests of different natures, avoiding the limitations of a single retrieval mode. Furthermore, precise query processing ensures the accuracy of technical parameter matching, solving the problem of low precision query accuracy in general vector retrieval; simultaneously, semantic query processing fully utilizes the hierarchical structure of the index tree and scenario summaries to achieve a precise mapping from high-level business intent to low-level technical implementation, solving the problem of poor business semantic understanding.

[0019] According to at least one embodiment of this disclosure, after finding the target interface through the index tree, the method further includes: inputting the target interface and scene summary into the large model, generating index results, and feeding them back to the user.

[0020] According to the above solution, the natural language generation capabilities of the large model are used to transform highly technical API information into business language that is easy for users to understand. Furthermore, by integrating retrieved technical parameters with business context, the problem of the disconnect between technical implementation and business intent is resolved.

[0021] According to a second aspect of this disclosure, an index tree construction method is provided, the method comprising: generating scene description text of an interface based on structured metadata of the interface; vectorizing the scene description text to obtain a semantic vector; vectorizing the structured metadata to obtain a structure vector; and merging different interfaces based on the semantic vectors and structure vectors of different interfaces to generate an index tree containing scene relationships of different interfaces.

[0022] According to the above scheme, by automatically generating scenario description text containing business semantics for API interfaces and combining it with structured metadata for bimodal vectorization processing, the generated index tree not only retains the business scenario relationships in the technical architecture of the interface (such as business systems and functional module divisions), but also incorporates the semantic associations of high-level business concepts. This transforms the API documentation from a collection of scattered technical parameters into a tree-structured knowledge collection with complete business semantics and clear structural logic.

[0023] According to a third aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, such that the processor performs a first or second aspect of any embodiment of this disclosure.

[0024] According to a fourth aspect of this disclosure, a readable storage medium is provided, wherein executable instructions are stored therein, which, when executed by a processor, are used to implement a first or second aspect of any embodiment of this disclosure.

[0025] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a first or second aspect of any embodiment of this disclosure. Attached Figure Description

[0026] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0027] Figure 1 This is a flowchart illustrating the interface indexing method provided in an embodiment of this disclosure.

[0028] Figure 2 This is a flowchart illustrating a target interface lookup method provided in an embodiment of the present disclosure.

[0029] Figure 3 This is a schematic flowchart of the vector generation method provided in an embodiment of this disclosure.

[0030] Figure 4 This is a flowchart illustrating the method for generating scene description text provided in an embodiment of this disclosure.

[0031] Figure 5 This is a flowchart illustrating the index tree generation method provided in an embodiment of this disclosure.

[0032] Figure 6 The following is a flowchart illustrating the index tree generation method in specific embodiments of this disclosure.

[0033] Figure 7 This is a flowchart illustrating another target interface lookup method provided in an embodiment of the present disclosure.

[0034] Figure 8 This is a flowchart illustrating the index tree creation method provided in an embodiment of this disclosure.

[0035] Figure 9 This is a schematic block diagram of an interface indexing device according to one embodiment of the present disclosure.

[0036] Figure 10 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure. Detailed Implementation

[0037] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0038] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0039] Figure 1 This is a flowchart illustrating the interface indexing method provided in an embodiment of this disclosure. Figure 1 The method shown includes steps S101 to S104. This method can be applied to the server side (which may be a local server, cloud server, etc.).

[0040] Specifically, Figure 1 The method shown includes step S101: in response to an interface index request, parsing the interface index request.

[0041] When a user's API indexing request is received, the request may contain both technical parameters and / or business semantics. For example, some API indexing requests contain clearly defined technical parameters, such as the specific API name and reference parameters. Others may only contain business semantics representing the user's needs; for instance, a user might say "find the API for adjusting the quantity of items in the shopping cart," without specific API parameters, only the API-related business semantics. Of course, some API indexing requests contain both API-related technical parameters and business semantics simultaneously.

[0042] Step S102: Based on the parsing results, find the target interface through the index tree.

[0043] In practical applications, the hierarchical relationships of different interfaces within the index tree are fully utilized, demonstrating a precise mapping from high-level business scenario concepts to low-level interface implementations through the node connections within the tree. For example, when a user inputs a business-level query such as "how to implement shopping cart checkout," the system first converts the interface index request into a semantic vector, and then calculates the semantic similarity between the query and each child node, starting from the root node of the index tree. During the query process, the hierarchical structure of the index tree is fully utilized for multi-level queries: for instance, if the system recognizes that the purpose of the interface index request is to find the node with the highest similarity to "Order Management" (rather than User Management or Inventory Management), it enters that branch; under the "Order Management" node, the system further compares and finds that the interface index request has the highest similarity to the "Order Creation" child node (0.91), and continues traversing downwards; finally, it locates the "createOrder" interface. Each level of this index tree represents a different granularity of business scenario concept abstraction, with the root node representing the broadest business domain, intermediate nodes at different levels representing different level scenario relationships, and leaf nodes representing specific interfaces. This hierarchical structure enables the system to understand that "shopping cart checkout" belongs to the "order creation" business scenario, and "order creation" belongs to the "order management" business scenario, thus accurately locating the specific interface of the technical implementation layer through the tree path. Step S103: Based on the structured metadata of the interface, generate the scenario description text of the interface.

[0044] It should be noted that structured metadata refers to the technical definition information of the API interface, including basic technical information such as the interface name, endpoint, request parameters, response parameters and their types, and brief descriptions, as well as structured information such as the business system to which it belongs, functional category, and development team. Scenario description text refers to natural language text generated based on the structured metadata of the interface using a large language model, describing the interface's business purpose, applicable scenarios, and the business domain to which it belongs.

[0045] In practical applications, under a distributed architecture, existing API documentation only records basic technical information and lacks key business semantics. Some interfaces have similar names but different actual business functions and scenarios, making it difficult for retrieval systems to distinguish them. This leads to the interface retrieval system being unable to understand the actual business purpose of the interface when users search for interfaces, potentially resulting in the retrieval of incorrect interfaces. One alternative solution is to inject business context into each interface using a large language model. For example, for an interface named "createOrder," its structured metadata includes interface-related information such as "POST / api / order, parameters: userId(String), items(List)." After being input into the large language model, it generates descriptive text rich in business semantics, such as "This interface is used to create user orders on e-commerce platforms, applicable to shopping cart checkout scenarios, and is a core function of the transaction system, handling order generation and inventory pre-allocation after users select goods." This business semantic expansion method effectively solves the problem of missing business context in API documentation, enabling subsequent searches to more accurately understand high-level business scenario concepts such as "placing an order" and "checkout," rather than simply matching literal keywords.

[0046] Step S104: Vectorize the scene description text to obtain a semantic vector; and vectorize the structured metadata to obtain a structure vector.

[0047] The semantic vectors mentioned here refer to high-dimensional vector representations obtained by vectorizing scene description text through text embedding models, used to capture the semantic information of the text. The structural vectors refer to vector representations obtained after feature encoding of structured metadata, used to characterize the structured features and business relationships of the interface.

[0048] In practical applications, semantic vectors can be converted from scenario description text into 768-dimensional high-dimensional vectors using text embedding models (such as BGE or Sentence-BERT). These vectors can capture the similarities and differences between different expressions or words, such as the semantic similarity between "order creation" and "shopping settlement," and the synonymous business concepts of "placing an order" and "creating an order." Structural vectors are formed by feature encoding of structured metadata (e.g., using One-Hot encoding for "belonging business system" and label encoding for "functional category"). For example, "transaction system" is encoded as [1,0,0], and "user system" is encoded as [0,1,0]. This encoding preserves the inherent hierarchy of the interface's business scenario, ensuring that "payment interface" is not incorrectly clustered with "user management interface." The combined use of these two types of vectors allows the system to both understand business semantics and adhere to the inherent hierarchical architecture constraints of the interface's business scenario.

[0049] Step S105: Merge different interfaces based on their semantic vectors and structural vectors to generate an index tree containing scene relationships of different interfaces.

[0050] The index tree mentioned here refers to a tree-shaped data structure generated through merging processing, where the leaf nodes are specific API interfaces, and the internal nodes of the index tree represent clusters of interfaces with similar business scenarios.

[0051] In practical applications, this process employs an improved hierarchical clustering algorithm. During initialization, each API interface is treated as an independent cluster, and then the inter-cluster distance is calculated: Distance = α × Semantic Distance + β × Structural Distance. For example, when comparing the "createOrder" and "payOrder" interfaces, the semantic distance measures the similarity of their business descriptions (potentially 0.3, indicating high relevance), while the structural distance measures the similarity of the systems they belong to (0 if both belong to the same transaction system, 1 if they belong to different systems). In an alternative approach, the merging process must meet the following condition: semantic distance is considered for merging only when the structural distance is sufficiently small (i.e., the interfaces belong to the same domain in terms of technical architecture). This approach ensures that the clustering results conform to both the actual technical hierarchy of the interfaces (e.g., interfaces within a transaction system are clustered together) and business semantic coherence (e.g., creating orders, paying orders, and querying orders form an order management cluster). In the final generated index tree, the leaf nodes are specific API interfaces, and the internal nodes are clusters of interfaces that are logically related to the business scenario. For example, the "Order Management" cluster contains interfaces related to order creation, payment, and query, while the "User Management" cluster contains interfaces related to user registration, login, and information modification.

[0052] Based on the publicly available solutions described above, by expanding business semantics, the system can understand high-level business concepts rather than simply matching literal keywords, thus solving the problem of poor semantic understanding. Furthermore, merging semantic vectors and structural vectors preserves the inherent scenario hierarchy of the API interface while establishing business semantic relationships, avoiding the structural information destruction issues common in general vector retrieval. During the query process, a scenario relationship index tree supports multi-level retrieval from high-level business intent to low-level interface parameters, enabling users to quickly locate the required interface using natural business language, improving interface query efficiency and accuracy.

[0053] In one or more embodiments of this disclosure, such as Figure 2This is a flowchart illustrating a target interface lookup method provided in an embodiment of this disclosure. Steps S101 and S102, in response to an interface index request, parse the interface index request; based on the parsing result, find the target interface through an index tree, including: Step S201: Parse the interface index request to obtain parameter information and scene information. Step S202: Find a first candidate interface from the interface database based on the parameter information. Step S203: Based on the scene information, traverse the index tree to find the second candidate interface and the scene summary in the corresponding parent node. Step S204: If the first candidate interface and the second candidate interface are the same, then the second candidate interface is taken as the target interface.

[0054] It should be noted that the parameter information mentioned here refers to the technical parameters contained in the interface index request, such as the interface name, request parameter name, parameter type, return type, and other structured technical features. The scenario information mentioned here refers to the business semantic description contained in the interface index request, such as multi-level business concepts like "user placing an order," "payment settlement," and "inventory query." The first candidate interface refers to the candidate API interface found through exact matching from the structured interface database based on the parameter information; the second candidate interface refers to the candidate API interface that best matches the business semantics, found through index tree traversal based on the scenario information. The scenario summary mentioned here refers to the summary corresponding to the business scenario description contained in each level of parent node on the path of the second candidate interface in the index tree, used to characterize the business functional module and domain context to which the interface belongs.

[0055] In practical applications, when users query an API, the API index request may simultaneously contain technical parameters and business semantics. For example, when the API index request is "How to implement order creation, requiring userId and items parameters", the system automatically parses the parameter information as "userId (String), items (List)" and the scenario information as "order creation". This dual-path parsing method fully considers the actual query habits of developers, that is, it includes both technical details and business intent. By extracting both types of information simultaneously, the system can more comprehensively understand the user's true intent.

[0056] After parsing, the precise matching capabilities of traditional structured databases are further utilized to efficiently retrieve parameter information. For example, when the parameter information is "userId(String), items(List)", the system quickly locates candidate interfaces with matching parameters in the interface database, such as "createOrder" (parameters: userId, items), "addToCart" (parameters: userId, items), and "createReservation" (parameters: userId, items). These three interfaces all accept parameters of the same type, but their business purposes are completely different.

[0057] Simultaneously, leveraging the advantages of the scenario relationship index tree, when the scenario information is "order creation," the system converts the interface index request into a semantic vector and / or into a structural vector, traversing layer by layer from the root node of the index tree. First, it identifies the "order management" node as the most relevant business domain (e.g., similarity 0.87) within the index tree. Then, it finds the child node "order creation" with a scenario relationship within this domain (e.g., similarity 0.92), ultimately locating the leaf node "createOrder" as the second alternative interface. The key advantage is that the system not only returns the matching interface but also obtains the complete business context, namely, a summary of the scenario of all parent nodes along the path from the root node to the interface. These summaries, generated by a large language model, clearly describe the interface's location and role in the business process. This index tree-based traversal method understands the business semantics of "order creation," avoiding confusion between "createOrder" and "addToCart," even though they have similar technical parameters.

[0058] It should be noted that, in addition, the similarity mentioned here refers to the high degree of consistency between the first and second alternative interfaces in terms of technical implementation and business functions. Not only do their technical features, such as interface names and parameter definitions, match, but their business uses, applicable scenarios, and business domains are also the same or highly similar.

[0059] Parameter-based retrieval may find multiple interfaces with similar technical parameters but different business applications, while scenario-based retrieval may return imprecise results due to semantic ambiguity. Only when both methods point to the same interface is it confirmed as the target interface, significantly improving the reliability of search results.

[0060] Based on the publicly available solutions described above, the dual analysis of parameter and scenario information balances technical accuracy with business semantic understanding, thus resolving the issue of incomplete coverage by a single search mode. Furthermore, the joint selection of the target interface by the first and second alternative interfaces effectively improves the accuracy of the search results.

[0061] In one or more embodiments of this disclosure, such as Figure 3 This is a schematic flowchart illustrating the vector generation method provided in an embodiment of this disclosure. Figure 3 As shown, step S102, which involves vectorizing the scene description text to obtain a semantic vector, and vectorizing the structured metadata to obtain a structure vector, includes: Step S301: Inputting the scene description text into the first model to extract semantic features. Step S302: Vectorizing the semantic features to obtain the semantic vector corresponding to the interface. And, Step S303: Inputting the structured metadata into the second model to obtain structural features representing the business relationships of the metadata; wherein, the structured metadata includes at least one of the following: the business system to which the interface belongs, the functional category, the business type, and the business purpose. Step S304: Vectorizing the structural features to obtain the structure vector corresponding to the interface.

[0062] The first model mentioned here is a text embedding model that has been pre-tuned on a large amount of API business description text, such as the BGE-large-zh model fine-tuned based on e-commerce platform API documentation. This model has undergone domain-adaptive training before deployment, with training data including historical enterprise API documentation and business scenario description text. For example, when given a scenario description text such as "This interface is used to create user orders on an e-commerce platform, applicable to shopping cart checkout scenarios, and belongs to the core functions of the transaction system," the first model extracts deep semantic features through a multi-layer Transformer structure. It can identify the business relevance between "creating user orders" and "shopping cart checkout," and understand the business importance hierarchy represented by "core functions of the transaction system." By utilizing the first model for semantic feature extraction, a vector space mapping of business semantics is achieved, enabling the system to recognize the semantic equivalence of the same business intent under different expressions, and to identify synonyms and different words with scenario hierarchy affiliations.

[0063] Furthermore, the extracted semantic features are converted into high-dimensional vectors of fixed dimensions (e.g., 768-dimensional), forming a unique representation in the semantic feature space. Vectorization preserves the topological structure of business semantics, constructing a continuous representation space for API business semantics. This enables the retrieval system to perform matching based on semantic similarity, rather than relying on literal keyword matching, significantly improving the understanding and matching accuracy of high-level business queries.

[0064] Simultaneously, a second model is used to extract features from the structured metadata of the API interfaces. For example, a second model trained based on historical API call relationships (e.g., a label-encoding neural network model). This second model has been trained using API topology data before deployment, learning the call dependencies between business systems. When structured metadata is input, such as "belonging business system: transaction system, function category: order management, business type: core transaction," the second model extracts structural features representing the interface's position within the enterprise's technical architecture using pre-defined encoding rules or a small neural network. For example, it identifies the association between the "transaction system" and the "payment system" within the same business scenario (due to their high call frequency in the actual architecture), while recognizing the "user system" as belonging to different business scenarios with lower correlation. By extracting structural features, objective topological constraints are effectively preserved, ensuring that the "payment interface" is not incorrectly clustered with the "user management interface."

[0065] The structural features are further transformed into vector representations in the structural feature space. For example, One-Hot encoding can be used to represent "Transaction System" as [1,0,0] and "Payment System" as [0,1,0], or graph embedding techniques can be used to generate more complex vector representations. Structural vectors effectively preserve the topological relationships of the business scenario architecture to which the interfaces belong; that is, interfaces belonging to the same "Transaction System" have a smaller Euclidean distance in the structural feature space, while interfaces from different systems have a larger distance. This ensures that the retrieval results conform to the structural constraints of the actual business scenario.

[0066] Based on the publicly available solutions described above, by extracting semantic vectors representing the business semantic feature space of API interfaces, the retrieval system can identify the semantic relationships between different levels of business scenarios; by extracting structural vectors representing the topological relationships of API interfaces within the technical architecture, it ensures that the retrieval results conform to the structural constraints of the system design. These two vector representation mechanisms enable API retrieval to possess both the flexibility of semantic understanding and the accuracy of technical architecture constraints, effectively solving the technical problems of insufficient semantic understanding capabilities and the destruction of structural information.

[0067] In one or more embodiments of this disclosure, such as Figure 4 This is a flowchart illustrating the scene description text generation method provided in an embodiment of this disclosure. Figure 4 As shown, step S103, which involves generating scene description text for an interface based on its structured metadata, specifically includes: Step S401: Constructing scene generation prompts using the interface's structured metadata and scene description information. Step S402: Inputting the scene generation prompts into the large model to generate the interface's scene description text.

[0068] In practical applications, the requirements for generating scenario description text are predefined through scenario description information. For example, "You are a senior system architect. Please generate a detailed business scenario description for the following API interface, explaining its business purpose, applicable scenarios, and business domain. The output length should be controlled between 150-200 characters." When processing the createOrder interface, its structured metadata is "POST / api / order, Parameters: userId(String), items(List)". <product>The API returns an `orderId(String)`, which is then combined according to a preset template to generate a prompt: "You are a senior system architect. Please generate a detailed business scenario description for the following API interface, explaining its business purpose, applicable scenarios, and business domain. The output length should be controlled between 150-200 characters. API information is as follows: Interface name: createOrder, Endpoint: POST / api / order, Parameters: userId(String), items(List) <product>), returns: orderId(String) .

[0069] The large model mentioned here has undergone domain-adaptive fine-tuning using historical API documentation and business scenario descriptions before deployment, enabling it to better understand specific business terminology and system architecture. Upon receiving the scenario-generated prompts, the large model can generate the following scenario description text: "This interface is used by the e-commerce platform to create user orders and handle the settlement process for items in the shopping cart. After the user completes their product selection, the front-end system calls this interface to submit the user ID and product list. The system verifies the inventory and generates a unique order ID, which is then returned. This interface belongs to the core module of the transaction system and is applicable to business scenarios such as user order placement and promotional activity settlement. It is the starting point of the order lifecycle and has a close calling relationship with the payment and inventory interfaces." The scenario description text generated by the large model fully covers the three essential dimensions: business purpose (creating user orders), applicable scenarios (shopping cart settlement, promotional activities), and business domain (core module of the transaction system).

[0070] Based on the publicly available solutions described above, the use of large-scale models to generate scenario description text solves the problem of missing business semantics in existing API documentation, enabling each interface to have a complete business context description. Furthermore, a unified prompt word template ensures the professionalism and consistency of the generated content, eliminating document quality differences caused by manual writing. The generated scenario description text accurately captures the interface's location and association within the business process, providing a foundation for subsequent semantic and structural retrieval.

[0071] In one or more embodiments of this disclosure, such as Figure 5 This is a flowchart illustrating the index tree generation method provided in an embodiment of this disclosure. Figure 5 As shown, step S105, which involves merging different interfaces based on their semantic and structural vectors to generate an index tree containing scene relationships of different interfaces, includes: Step S501: Calculating the first similarity between any two interfaces among multiple different interfaces based on semantic vectors. Step S502: Calculating the second similarity between any two interfaces among multiple different interfaces based on structural vectors. Step S503: Calculating the comprehensive similarity between the two interfaces using the first and second similarities. Step S504: Recursively searching for two interfaces to be merged that have the highest comprehensive similarity and a second similarity greater than a similarity threshold. Step S505: Merging the two interfaces to be merged to generate an index tree containing scene relationships of different interfaces.

[0072] In practical applications, cosine similarity can be used to calculate the similarity between the semantic vectors of two interfaces in the semantic feature space. For example, the formula is: Cosine distance Sim_sem(I_i, I_j) = (V_sem_i · V_sem_j) / (||V_sem_i|| × ||V_sem_j||), where V_sem_i and V_sem_j represent two different semantic vectors. For instance, for the interfaces "createOrder" and "payOrder", their semantic vectors are V1 and V2 respectively. The calculated first similarity is 0.85, indicating that they are highly related in terms of business semantics (both involve order processing). However, the first similarity between "createOrder" and "userLogin" is only 0.23, indicating a weaker business semantic association. Here, a smaller cosine distance indicates a greater first similarity.

[0073] In the structural feature space, Jaccard similarity can be used to calculate the similarity between two interface structural vectors, expressed by the formula: Sim_struct(I_i, I_j) = |F_i ∩ F_j| / |F_i ∪ F_j|, where F_i and F_j represent two different sets of structural features. For example, createOrder and cancelOrder belong to the same order management module of a transaction system, and their structural features highly overlap (same system identifier, functional classification, etc.), resulting in a second similarity of 0.92; while createOrder and userProfile belong to different business systems, and their second similarity is only 0.18. Similarly, the smaller the calculated structural distance, the greater the corresponding second similarity.

[0074] After calculating the two similarities as described above, a weighted average method can be used to further calculate: Sim_composite(I_i, I_j) = α × Sim_sem(I_i, I_j) + β × (1 - Dist_struct(I_i, I_j)), where α and β are weighting coefficients (α+β=1), and Dist_struct represents the structural distance. By converting the structural distance into a similarity representation (1-Dist_struct), the two metrics are ensured to be fused on the same scale. For example, when α=0.7 and β=0.3, the combined similarity between createOrder and payOrder is 0.7×0.85+0.3×0.92=0.871; while the combined similarity between createOrder and addToCart (semantic similarity 0.78, structural similarity 0.85) is 0.7×0.78+0.3×0.85=0.791. The method of fusing the two similarity scores takes into account both the semantic relevance of business and the constraints of the technical architecture.

[0075] Furthermore, the system recursively searches for two interfaces to be merged that have the highest overall similarity and a second similarity greater than a similarity threshold. Using the second similarity threshold as a hard constraint ensures that only interfaces with sufficiently similar technical architectures are considered for merging. For example, setting the second similarity threshold to 0.75, in each iteration, the system: 1) filters out all interface pairs with a second similarity > 0.75; 2) selects the pair with the highest overall similarity from the filtering results (e.g., createOrder and payOrder, overall similarity 0.871); 3) selects this pair as the interfaces to be merged. If an interface pair has high semantic similarity (e.g., createOrder and inventoryCheck, semantic similarity 0.82), but its second similarity is only 0.68 (below the threshold), it is excluded from the merging candidates. This structural vector constraint method ensures that the technical architecture relationships of the interfaces are preserved to the maximum extent when building the index tree, effectively avoiding incorrect clustering of interfaces from different scenarios due to semantic similarity.

[0076] Furthermore, the two selected interfaces are merged into a new cluster node. The semantic vector of this node is the weighted average of the semantic vectors of the original two interfaces, and the structural vector is the intersection feature of the structural vectors of the original two interfaces. For example, after merging createOrder and payOrder, the new cluster node represents the business scenario concept of "order transaction processing". Its semantic vector reflects the comprehensive semantic features of this business domain, and its structural vector retains the common attributes of the transaction system. The above recursive process is repeated until all interfaces are merged into a single root node, forming a complete index tree. In this tree structure, the leaf nodes are specific API interfaces, and the internal nodes are business logic-related interface clusters (such as order management, payment processing, etc.). The node relationships all conform to the technical architecture constraints (the second similarity of interfaces within the same cluster is greater than the threshold), while maintaining business semantic coherence (the first similarity of interfaces within the cluster is relatively high).

[0077] Based on the publicly available solutions described above, the second similarity threshold constraint mechanism ensures that the index tree effectively preserves the technical architecture relationships between nodes (i.e., the scenario relationships of interfaces), preventing semantically similar but architecturally unrelated interfaces from being incorrectly clustered. Furthermore, the comprehensive similarity calculation method integrates both business semantics and technical architecture features, maintaining the flexibility of semantic retrieval while ensuring the rigor of technical constraints, thus enabling the index tree to possess both business semantic and technical architecture layers.

[0078] In one or more embodiments of this disclosure, such as Figure 6 This is a flowchart illustrating the index tree generation method in specific embodiments of this disclosure. Figure 6 As shown, merging two interfaces to be merged generates an index tree containing scene relationships of different interfaces, including: Step S601: After merging all interfaces, treat all interfaces as leaf nodes and the scene hierarchy as parent nodes. Step S602: Calculate the scene summary of the parent node using the large model. Step S603: Construct an index tree containing scene relationships of different interfaces based on the leaf nodes and the parent nodes containing the scene summaries.

[0079] After merging all interfaces, all interfaces are treated as leaf nodes, and the scenario hierarchy is treated as the parent node. During hierarchical clustering, the system recursively merges interfaces with high semantic and structural similarity into higher-level business scenario concept nodes, ultimately forming an index tree with a multi-level abstract tree structure. For example, in an e-commerce platform API system, specific interfaces such as createOrder, payOrder, and cancelOrder are treated as leaf nodes and are first merged into the "Order Operation" hierarchy (first-level parent node); "Order Operation" and "queryOrder" are further merged into the "Order Management" hierarchy (second-level parent node); "Order Management" and modules such as "paymentProcessing" are finally merged into the "Transaction System" root node. The connections between nodes in the index tree fully preserve the business scenario relationships of the API interfaces. That is, the connection between a leaf node and its parent node indicates that the interface belongs to a specific business scenario, and the connection between a parent node and its root node indicates that the business scenario belongs to a broader business domain. This hierarchical organization not only preserves the technical relationships between interfaces but also clearly expresses the business scenario evolution path of "createOrder → order operation → order management → transaction system," enabling users to intuitively understand the position of the interface in the entire business process. In actual systems, this tree structure accurately reflects the hierarchy of the business architecture.

[0080] For each parent node, the system collects business description information from its child nodes (including leaf nodes and other parent nodes) and constructs a summary generation prompt: "You are a senior system architect. Please summarize the common business characteristics of the following API interfaces, describe their respective business domains and core functions, and output 100-150 words. Interface list: [Child node information]". The large model has been fine-tuned for the domain using enterprise business documents before deployment, enabling it to generate summaries that accurately reflect the business scenario.

[0081] For example, for the parent node "Order Operations" containing createOrder, payOrder, and cancelOrder, the large model generates a scenario summary: "This module handles the core operations in the order lifecycle, including order creation, payment processing, and cancellation. It is suitable for scenarios such as user shopping settlement and order modification, and is a key link in the order management process, interacting closely with the inventory system and payment system." This scenario summary not only summarizes the common business characteristics of the child nodes, but also clearly indicates the position and relationship of this business scenario in the overall business process, giving each level of the index tree a clear business semantic explanation.

[0082] The system organizes leaf nodes and their parent nodes with scenario summaries into a hierarchical tree structure. Each node contains its business semantic information and its relationships with adjacent nodes. For example, in the constructed index tree, the `createOrder` leaf node is connected to the order management grandparent node (scenario summary: managing the entire lifecycle of user orders, including creation, querying, modification, and cancellation) through the order operation parent node (scenario summary: handling core operations in the order lifecycle...), and finally to the root node of the transaction system. The key value of this structure is that it fully preserves the business scenario relationship chain between interfaces. This hierarchical organization makes business semantic relationships visible; for example, developers can immediately see the close relationship between `createOrder` and `payOrder` (both belonging to the order operation level), while the relationship with `userProfile` is weaker (requiring a higher-level connection).

[0083] Based on the publicly available solutions described above, the tree-structured connections between nodes fully preserve the business scenario hierarchy and relationships of the API interfaces, enabling users to intuitively understand the interface's positioning and interrelationships within the business process. Furthermore, the scenario summary of the parent node provides a clear semantic explanation for each business abstraction level, making implicit business relationships explicit and avoiding the problem of missing business semantics in the API documentation.

[0084] In one or more embodiments of this disclosure, such as Figure 7 This is a flowchart illustrating another target interface lookup method provided in an embodiment of this disclosure. Figure 7 As shown, steps S101 and S102, in response to an interface index request, parse the interface index request; based on the parsing result, find the target interface through the index tree, including: Step S701: In response to the interface index request, determine the query type of the interface index request. Step S702: If the query type is an exact query, find the target interface from the interface database according to the parameter information carried in the interface index request. Step S703: If the query type is a semantic query, traverse the index tree to the target interface and the corresponding parent node's scene summary.

[0085] The query type is determined by analyzing the text features of the interface index request: when the request contains explicit technical parameter identifiers (e.g., keywords such as parameter, type, field, interface name, etc.) or uses technical phrases (e.g., searching for interfaces that accept String type userId parameters), it is determined to be an exact query. When the request contains business semantic descriptions (e.g., keywords such as how, implementation, business, process, etc.) or uses natural language to express business requirements (e.g., how to handle failed user orders), it is determined to be a semantic query. In an optional solution, this determination process can be implemented using a pre-trained text classification model, which has been trained on historical query logs before deployment. For example, when receiving the interface index request "What is the parameter type of the getOrderById interface?", the system identifies technical keywords such as "interface" and "parameter type" and determines it to be an exact query. This automatic query type identification method avoids the barrier of requiring users to explicitly specify the query method, making it convenient for users to search.

[0086] In precise query processing, the system parses the query into structured query conditions and performs precise matching directly in the technical parameter index. This method inherits the high-precision advantages of traditional keyword retrieval and is particularly suitable for handling scenarios requiring strict matching of technical parameters, such as interface debugging and code completion during development.

[0087] In semantic query processing, the system first converts the query into a semantic vector. Then, starting from the root node of the index tree, it calculates the semantic similarity between the query and each child node, selects the most relevant branch, and traverses downwards until the most matching leaf node (target interface) is located. This method fully utilizes the hierarchical structure of the index tree and the parent node scene summaries, finding the target interface through multiple levels based on the index tree branching relationships. When querying the target interface, it not only returns the target interface but also obtains the scene summaries of all parent nodes along the complete path from the root node to that interface.

[0088] Based on the aforementioned publicly available solutions, the automatic query type identification mechanism employs the optimal retrieval strategy for query requests of different natures, avoiding the limitations of a single retrieval mode. Furthermore, precise query processing ensures the accuracy of technical parameter matching, resolving the issue of low precision query accuracy in general vector retrieval; simultaneously, semantic query processing fully utilizes the hierarchical structure of the index tree and scenario summaries, achieving a precise mapping from high-level business intent to underlying technical implementation, thus addressing the problem of poor business semantic understanding.

[0089] In one or more embodiments of this disclosure, after finding the target interface through the index tree, the method further includes: inputting the target interface and scene summary into the large model, generating index results and feeding them back to the user.

[0090] In a distributed architecture, due to the large number of interfaces, many of which have similar names and functions, users sometimes struggle to quickly understand how to use them. Therefore, a large model is used to integrate retrieved technical information with business context, generating index results that are both accurate and easy to understand. Index tree retrieval ensures the accuracy and relevance of the input information, while large model generation translates technical details into business language that developers can easily understand.

[0091] Based on the publicly available solutions described above, the natural language generation capabilities of large-scale models can transform highly technical API information into business language that is easy for users to understand. Furthermore, by integrating retrieved technical parameters with business context, the problem of the disconnect between technical implementation and business intent is resolved.

[0092] Based on the same idea, this disclosure also proposes a method for building an index tree. For example... Figure 8 This is a flowchart illustrating the index tree creation method provided in an embodiment of this disclosure. Figure 8 As shown, step S801: Generate scene description text for the interface based on the structured metadata of the interface. Step S802: Vectorize the scene description text to obtain semantic vectors. Step S803: Vectorize the structured metadata to obtain structure vectors. Step S804: Merge different interfaces based on the semantic vectors and structure vectors of different interfaces to generate an index tree containing scene relationships of different interfaces.

[0093] The implementation process of this solution can be found in [link to relevant documentation]. Figure 1 The corresponding implementation examples will not be repeated here. Based on the above-disclosed solutions, by automatically generating scenario description text containing business semantics for API interfaces and combining it with structured metadata for bimodal vectorization processing, the generated index tree not only retains the business scenario relationships in the interface's technical architecture (such as business systems and functional module divisions) but also incorporates the semantic associations of high-level business concepts. This transforms the API documentation from a collection of scattered technical parameters into a tree-structured knowledge collection with complete business semantics and clear structural logic.

[0094] Based on any of the above embodiments, this disclosure also provides an interface indexing device. Figure 9 This is a schematic block diagram of the interface indexing device according to one embodiment of this disclosure. Figure 9 As shown, the interface indexing device includes: a parsing module 901, used to parse the interface indexing request in response to the request; a search module 902, used to search for the target interface through the index tree based on the parsing result; a generation module 903, used to generate scene description text for the interface based on its structured metadata; a vectorization module 904, used to vectorize the scene description text to obtain semantic vectors, and to vectorize the structured metadata to obtain structure vectors; and a generation module 905, used to merge different interfaces based on their semantic and structure vectors to generate an index tree containing scene relationships between the different interfaces.

[0095] The lookup module 902 is used to parse the interface index request to obtain parameter information and scene information; based on the parameter information, it searches for the first candidate interface in the interface database; based on the scene information, it traverses the index tree to find the second candidate interface and the scene summary in the corresponding parent node; if the first candidate interface and the second candidate interface are the same, the second candidate interface is taken as the target interface.

[0096] The vectorization module 904 is used to input the scene description text into the first model to extract semantic features; to perform vectorization processing on the semantic features to obtain the semantic vector corresponding to the interface; and to input the structured metadata into the second model to obtain the structural features representing the business relationship of the metadata; to perform vectorization processing on the structural features to obtain the structural vector corresponding to the interface.

[0097] The generation module 905 is used to construct scene generation prompts using the structured metadata and scene description information of the interface; the scene generation prompts are input into the large model to generate the scene description text of the interface.

[0098] The generation module 905 is used to calculate the first similarity between any two interfaces among multiple different interfaces based on semantic vectors; and to calculate the second similarity between any two interfaces among multiple different interfaces based on structural vectors; to calculate the comprehensive similarity between the two interfaces using the first and second similarities; to recursively find the two interfaces to be merged that have the largest comprehensive similarity and a second similarity greater than the similarity threshold; and to merge the two interfaces to be merged to generate an index tree containing the scene relationships of different interfaces.

[0099] The generation module 905 is used to, after merging all interfaces, treat all interfaces as leaf nodes and scene levels as parent nodes; calculate the scene summary of the parent node using the large model; and construct an index tree containing scene relationships of different interfaces based on the leaf nodes and the parent nodes containing scene summaries.

[0100] The lookup module 902 is used to respond to the interface index request and determine the query type of the interface index request. If the query type is an exact query, the target interface is found from the interface database based on the parameter information carried in the interface index request. If the query type is a semantic query, the scenario summary is found by traversing the index tree to the target interface and the corresponding parent node.

[0101] The search module 902 is used to input the target interface and scene summary into the large model, generate index results, and provide feedback to the user.

[0102] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0103] The entity executing the information sending method in the specific embodiments of this disclosure may be an electronic device such as a server (including a local server or a cloud computing platform).

[0104] Therefore, based on any of the above embodiments, this disclosure also provides an electronic device that can execute the interface indexing method of any of the embodiments described above.

[0105] Figure 10 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure.

[0106] The hardware architecture of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application of the hardware and overall design constraints. Bus 1100 connects various circuits, including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400, such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.

[0107] Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one connection line is used in this diagram, but this does not imply that there is only one bus or only one type of bus.

[0108] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. "Readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of readable storage media include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0109] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0110] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0111] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product 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.

[0112] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this disclosure. 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 illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0113] 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.

[0114] 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.

[0115] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, or characteristic described in connection with that embodiment / mode or example is included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0116] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0117] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.< / product> < / product>

Claims

1. An interface indexing method, characterized in that, The method includes: In response to an interface index request, the interface index request is parsed; Based on the parsing results, the target interface is found through the index tree; The index tree is established by: generating scene description text for the interface based on the structured metadata of the interface; vectorizing the scene description text to obtain semantic vectors; and vectorizing the structured metadata to obtain structure vectors; and merging different interfaces based on the semantic vectors and structure vectors of different interfaces to generate an index tree containing scene relationships of different interfaces.

2. The interface indexing method according to claim 1, characterized in that, The response to the interface index request is to parse the interface index request; Based on the parsing results, the target interface is found through the index tree, including: Parse the interface index request to obtain parameter information and scenario information; Based on the parameter information, the first alternative interface is found from the interface database; Based on the scene information, the scene summary is traversed through the index tree to the second alternative interface and the corresponding parent node. If the first candidate interface and the second candidate interface are the same, then the second candidate interface shall be used as the target interface.

3. The interface indexing method according to claim 1, characterized in that, The process of vectorizing the scene description text to obtain a semantic vector and vectorizing the structured metadata to obtain a structure vector includes: The scene description text is input into the first model to extract semantic features; The semantic features are vectorized to obtain the semantic vector corresponding to the interface; and, The structured metadata is input into the second model to obtain structural features that characterize the business relationships of the metadata; The structural features are vectorized to obtain the structural vector corresponding to the interface.

4. The interface indexing method according to claim 1, characterized in that, Based on the structured metadata of the interface, generate scenario description text for the interface, including: Using the structured metadata and scene description information of the interface, scene generation prompts are constructed; The scene-generating prompts are input into the large model to generate the scene description text for the interface.

5. The interface indexing method according to claim 1, characterized in that, Based on the semantic vectors and structural vectors of different interfaces, the different interfaces are merged to generate an index tree containing scene relationships of different interfaces, including: Calculate the first similarity between any two interfaces among multiple different interfaces based on the semantic vector; and... Calculate the second similarity between any two interfaces among multiple different interfaces based on the structure vector; The combined similarity between the two interfaces is calculated using the first similarity and the second similarity. The two interfaces to be merged are found recursively, one with the highest overall similarity and the other with a similarity greater than the similarity threshold. The two interfaces to be merged are merged to generate an index tree containing the scene relationships of the different interfaces.

6. The interface indexing method according to claim 5, characterized in that, The two interfaces to be merged are merged to generate an index tree containing the scene relationships of the different interfaces, including: After merging all interfaces, treat all interfaces as leaf nodes and the scene hierarchy as the parent node. Calculate the scene summary of the parent node using a large model; Based on the leaf nodes and the parent nodes containing the scene summary, an index tree containing scene relationships with different interfaces is constructed.

7. The interface indexing method according to claim 1, characterized in that, In response to an interface index request, the interface index request is parsed; based on the parsing result, the target interface is searched through an index tree, including: In response to the interface index request, determine the query type of the interface index request; If the query type is an exact query, the target interface is found from the interface database based on the parameter information carried in the interface index request; If the query type is a semantic query, then the scene summary is traversed to the target interface and its corresponding parent node based on the index tree.

8. A method for building an index tree, characterized in that, The method includes: Based on the structured metadata of the interface, generate the scenario description text of the interface; The scene description text is vectorized to obtain a semantic vector; The structured metadata is vectorized to obtain a structure vector; Based on the semantic vectors and structural vectors of different interfaces, the different interfaces are merged to generate an index tree containing scene relationships of different interfaces.

9. An electronic device, characterized in that, include: The memory stores execution instructions; as well as, A processor that executes execution instructions stored in the memory, causing the processor to perform the method of any one of claims 1 to 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 8.

Images