Service recommendation decision method and related device based on large model retrieval enhanced generation

Abstract

The application provides a service recommendation decision method based on large model retrieval enhancement generation and related equipment, and the method comprises the following steps: obtaining unstructured service demand; calling a large language model to perform semantic analysis and expansion on the service demand, and generating unstructured expanded semantic text; encoding the expanded semantic text to obtain a semantic query vector; querying pre-stored service descriptions of each service from a service database, respectively calculating a first similarity score between the semantic query vector and the service description, a second similarity score between each keyword in the expanded semantic text and the service description, and screening out a candidate service set having semantic correlation with the service demand; determining all application programming interfaces corresponding to the candidate service set, and screening out a final application programming interface set and recommending the same according to the semantic similarity between the use frequency, the label and the semantic query vector of each application programming interface. The application improves the accuracy of API recommendation.

Description

Technical Field

[0001] This invention relates to the field of service recommendation technology, and in particular to a service recommendation decision-making method and related equipment based on large model retrieval enhancement generation. Background Technology

[0002] Service recommendation decision systems are becoming increasingly important in today's digital ecosystem. These systems are intelligent systems that automatically recommend suitable API combinations to developers based on user input, considering factors such as compatibility, dependencies, and technical suitability among various Application Programming Interfaces (APIs). With the rapid development of cloud computing and web services, developers often need to select and combine service sets that meet business requirements from a large number of overlapping, heterogeneous, and constantly evolving APIs when building applications.

[0003] Service recommendation requires not only a thorough understanding of users' natural language needs but also consideration of the compatibility and technical dependencies between various APIs. Traditional recommendation methods (such as collaborative filtering, content-based matching, or graph-based analysis), while proven effective in product recommendation, often struggle to identify and handle these complex technical relationships in service recommendation tasks, leading to inaccurate API recommendations based on user needs. Furthermore, these traditional methods rely on extensive historical data for analysis and decision-making; their accuracy drops significantly when new APIs are released or frequently updated. Therefore, a service recommendation decision-making method and related equipment based on large-model retrieval enhancement are needed. Summary of the Invention

[0004] This invention provides a service recommendation decision-making method based on large model retrieval enhancement, which improves the technical problem of poor recommendation accuracy caused by the inability of existing technologies to fully consider the technical compatibility between various APIs when recommending APIs.

[0005] This invention provides a service recommendation decision-making method based on large-scale model retrieval enhancement. The method includes: acquiring unstructured service requirements; calling a large language model to perform semantic parsing and expansion on the service requirements, generating unstructured expanded semantic text; encoding the expanded semantic text to obtain a semantic query vector; querying pre-stored service descriptions of each service from a service database, and calculating a first similarity score between the semantic query vector and the service description, and a second similarity score between each keyword in the expanded semantic text and the service description, to obtain a comprehensive score for each service, and thereby selecting a set of candidate services that are semantically related to the service requirements; wherein, the service description is used to characterize the functional characteristics of the corresponding service; determining all application programming interfaces (APIs) corresponding to the candidate service set, and based on the usage frequency of various APIs, their preset tags, and the semantic similarity between them and the semantic query vector, calling the large language model to select the final set of APIs and make recommendations; wherein, each service corresponds to at least one API, and each API has at least one preset tag characterizing its technical characteristics.

[0006] In one embodiment of the present invention, the step of calling the large language model to perform semantic parsing and expansion on the service requirements to generate unstructured extended semantic text includes: calling the large language model to perform semantic parsing on the service requirements to generate semantic text; and calling the large language model again to perform semantic completion processing on the semantic text to generate extended semantic text with a unified expression style.

[0007] In one embodiment of the present invention, encoding the extended semantic text to obtain a semantic query vector includes: preprocessing the extended semantic text to obtain the final extended semantic text; and encoding the final extended semantic text to obtain a semantic query vector.

[0008] In one embodiment of the present invention, the preprocessing of the extended semantic text to obtain the final extended semantic text includes: segmenting the extended semantic text into sentences; removing stop words from the segmented extended semantic text to obtain the final extended semantic text.

[0009] In one embodiment of the present invention, the step of querying the service description codes of each service from the service database, and calculating the first similarity score between the semantic query vector and the service description code, and the second similarity score between each keyword in the extended semantic text and the service description code, to obtain a comprehensive score for each service, and thereby selecting a set of candidate services that are semantically related to the service requirement, includes: querying the service descriptions of each service from the service database; for each service: encoding the service description corresponding to the service to obtain a service description code; calculating the cosine similarity between the semantic query vector and the service description code to obtain a first similarity score between the service and the service requirement; calculating the relevance score between each keyword in the extended semantic text and the service description corresponding to the service based on the BM25 algorithm to obtain a second similarity score between the service and the service requirement; weighted summing the first similarity score and the second similarity score to obtain a comprehensive score for the service; sorting all services according to their corresponding comprehensive scores, and selecting services whose comprehensive scores are greater than a preset score threshold or whose comprehensive scores are among the top N as a set of candidate services; where N is a positive integer.

[0010] In one embodiment of the present invention, the step of calculating the relevance score between each keyword in the extended semantic text and the service description corresponding to the service based on the BM25 algorithm to obtain the second similarity score of the service includes: for each keyword in the extended semantic text: calculating the relevance score between the keyword and the service description corresponding to the service. Where ws(w,m) is the relevance score between keyword w and service description of service m, f(w,m) is the frequency of keyword w in service description of service m, k1 and b are preset parameters, |m| is the length of service description, and agdl is the average length of all service descriptions; by summing the relevance scores between all keywords in the extended semantic text and the corresponding service descriptions, a second similarity score between the service and the service requirement is obtained.

[0011] In one embodiment of the present invention, the step of determining all application programming interfaces (APIs) corresponding to the candidate service set, and based on the usage frequency of various APIs, the semantic similarity between their corresponding tags and the semantic query vector, and calling the large language model to filter out the final API set and make recommendations, includes: summarizing all APIs corresponding to each service in the candidate service set to form a candidate API set; wherein each service corresponds to at least one API; counting the usage frequency of each API in the candidate API set, arranging various APIs in order based on usage frequency, and selecting the top L APIs with the highest usage frequency to form a first target interface sequence; wherein L is a positive integer; for each API in the candidate API set: determining its corresponding tag and calculating the semantic similarity between the tag and the semantic query vector; sorting all APIs according to semantic similarity, and selecting the top T APIs to form a second target interface sequence; wherein T is a positive integer; summarizing the first target interface sequence and the second target interface sequence, and calling the large language model to obtain the final API sequence and make recommendations.

[0012] In one embodiment of the present invention, the step of sorting all application programming interfaces (APIs) based on semantic similarity and selecting the top T APIs as the second target interface sequence includes: sorting all APIs based on semantic similarity to form a candidate interface sequence; sequentially selecting APIs from the candidate interface sequence; for each selected API: determining whether the API is not in the first target interface sequence; if so, adding the API to the second target interface sequence and continuing to select new APIs until the second target interface sequence contains T types of APIs or all APIs have been selected; wherein the initial state of the second target interface sequence is an empty set; otherwise, continuing to select new APIs until all APIs have been selected.

[0013] In one embodiment of the present invention, the step of summarizing the first target interface sequence and the second target interface sequence, and calling the large language model to obtain the final application programming interface sequence and make recommendations includes: summarizing the first target interface sequence and the second target interface sequence to form a candidate target interface sequence; for each candidate target application programming interface in the candidate target interface sequence: based on the thought chain reasoning strategy, calling the large language model, and analyzing the candidate target application programming interface based on the semantic query vector and all tags and service descriptions of the candidate target application programming interface to determine whether the candidate target application programming interface is the final recommended interface; summarizing all the final recommended interfaces to form the final application programming interface sequence and make recommendations.

[0014] In one embodiment of the present invention, the step of using the thought chain reasoning strategy to invoke the large language model and analyze the candidate target application programming interface (API) based on the semantic query vector, the tags and service descriptions of the candidate API, and determining whether the candidate API is the final recommended interface includes: inputting the semantic query vector, all tags and service descriptions of the candidate API into the large language model, performing structured reasoning to obtain the adaptation conclusion of the candidate API; determining whether the adaptation conclusion meets the adaptation conditions set based on the service requirements: if it meets the conditions, then the candidate API is the final recommended interface; if it does not meet the conditions, then the candidate API is not the final recommended interface.

[0015] In one embodiment of the present invention, determining whether the adaptation conclusion meets the adaptation conditions set based on the service requirements includes: parsing the adaptation conclusion to obtain the function matching conclusion and the technical compatibility conclusion; determining whether the function matching conclusion meets the function matching conditions set by the service requirements, and whether the technical compatibility conclusion meets the interface compatibility requirements; if both meet, the adaptation conclusion meets the adaptation conditions set based on the service requirements; otherwise, the adaptation conclusion does not meet the adaptation conditions set based on the service requirements.

[0016] In one embodiment of the present invention, the step of selecting and recommending the final set of application programming interfaces (APIs) includes: generating a structured JSON object from the final set of APIs and recommending it; wherein the JSON object includes the service requirements and the various APIs ultimately recommended.

[0017] This invention also provides a service recommendation decision system based on large-scale model retrieval enhancement. The system includes: a service requirement acquisition module for acquiring unstructured service requirements; a semantic parsing module for calling a large language model to perform semantic parsing and expansion on the service requirements, generating unstructured expanded semantic text; an encoding module for encoding the expanded semantic text to obtain a semantic query vector; a service matching module for querying pre-stored service descriptions of each service from a service database, and calculating a first similarity score between the semantic query vector and the service description, and a second similarity score between each keyword in the expanded semantic text and the service description, to obtain a comprehensive score for each service, and thereby filter out a set of candidate services that are semantically related to the service requirements; wherein, the service description is used to characterize the functional characteristics of the corresponding service; and an interface filtering module for determining all application programming interfaces (APIs) corresponding to the candidate service set, and based on the usage frequency of various APIs, their preset tags, and the semantic similarity between them and the semantic query vector, calling the large language model to filter out the final set of APIs and make recommendations; wherein, each service corresponds to at least one API, and each API has at least one preset tag characterizing its technical characteristics.

[0018] The present invention also provides an electronic device, comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device enables the service recommendation decision-making method based on large model retrieval enhancement generation as described above.

[0019] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer's processor, causes the computer to perform any of the above-mentioned service recommendation decision-making methods based on large model retrieval enhancement generation.

[0020] The beneficial effects of this invention are as follows: This invention proposes a service recommendation decision-making method and related equipment based on large-model retrieval enhancement. It introduces a large language model to semantically parse and expand unstructured service requirements, generating extended semantic text with a unified style. Furthermore, it uses a dual similarity calculation strategy to filter pre-existing services, obtaining a set of candidate services with high relevance to the user's service requirements. Combining this with the API information associated with the services, and comprehensively considering the frequency of interface usage, tag characteristics, and the degree of matching with service requirements, it selects API recommendation results that match the user's needs. This invention is applicable to dynamic service recommendation and decision-making scenarios in dynamic service ecosystems, significantly improving the accuracy of API recommendations. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0022] In the attached diagram:

[0023] Figure 1 This is a flowchart illustrating a service recommendation decision-making method based on large model retrieval enhancement provided in an embodiment of the present invention;

[0024] Figure 2 A bar chart comparing experimental results from different methods;

[0025] Figure 3 This is a structural block diagram of a service recommendation decision system based on large model retrieval enhancement provided in one embodiment of the present invention;

[0026] Figure 4 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present invention. Detailed Implementation

[0027] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0028] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. The drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0029] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0030] The inventors discovered that service composition recommendation requires not only understanding the independent capabilities of each service but also modeling the interaction mechanisms, dependencies, and overall efficiency of services in collaboratively completing tasks. Therefore, compared to traditional product recommendation tasks, service composition recommendation is significantly more technically challenging. Consequently, in today's dynamically evolving service environment, traditional service recommendation systems (such as collaborative filtering, content-based matching, or graph neural network-based systems) are insufficient. This is because as services continuously introduce new features, release new versions, or become obsolete, service recommendation systems must possess a deep understanding of the context and accurate judgment of the technical compatibility between services. Especially when the goal of service recommendation is no longer selecting a single service but recommending a set of services that can collaboratively meet the needs of complex applications, existing service recommendation systems often fail to accurately recommend corresponding API combinations.

[0031] Over the past decade, service recommendation methodologies have undergone significant evolution. Early methods, represented by Collaborative Filtering (CF), made recommendations based on historically successful service compositions and usage patterns. While CF performed well in simple scenarios, it suffered from a cold start problem when faced with new services and struggled to handle the complex technical constraints involved in service composition. Content-Based Filtering attempted to compensate for this deficiency by analyzing service descriptions and API specifications; however, it still struggled to capture deep structures such as service orchestration and dependencies, and exhibited significant shortcomings in semantic understanding and service interoperability.

[0032] To overcome these limitations, most existing service recommendation systems employ Graph Neural Networks (GNNs) to model the service ecosystem as a multi-node, multi-relationship graph structure. These methods capture potential relationships and compatibility patterns between services by constructing a service co-occurrence graph. However, GNNs still face several challenges: firstly, the co-occurrence graph contains significant noise, affecting inference accuracy; secondly, while GNNs are capable of modeling complex relationships, they struggle to accurately identify the truly critical dependencies and interaction patterns during service integration. Furthermore, like traditional methods, GNNs require frequent model retraining in the face of dynamic environments with frequent service evolution and the continuous introduction of new services, making them ill-suited to rapidly changing and iterating service ecosystems.

[0033] The inventors further discovered that the continuous development of Large Language Models (LLMs) and Retrieval-Augmented Generation (RAG) frameworks has introduced new ideas for the design of service recommendation systems. By combining the natural language understanding capabilities of LLMs with the ability of RAG to integrate the latest technical documentation, this method can address several long-standing challenges in service recommendation. For example, it can alleviate the cold start problem by understanding the documentation information of new services without relying on historical usage data; and by analyzing API specifications, integration guidelines, and version constraints, it can more accurately identify the actual dependencies and compatibility requirements between various services. Furthermore, because this approach relies on the understanding and retrieval of current service documentation during the recommendation process, rather than on static model parameters obtained from historical data, it can dynamically adapt to service updates and new releases without retraining the model when new services are introduced.

[0034] To address the aforementioned issues and considering the interrelationship between the large language model and the retrieval enhancement generation framework discovered by the inventors, this invention provides a service recommendation decision-making method based on large model retrieval enhancement generation. It introduces a large language model to semantically parse and expand unstructured service requirements, generating extended semantic text with a unified style. A dual similarity calculation strategy is then used to filter pre-existing services, obtaining a set of candidate services with high relevance to the user's service requirements. Furthermore, by combining the API information associated with the services and comprehensively considering the frequency of interface usage, tag characteristics, and the degree of matching with service requirements, API recommendation results that align with the user's needs are selected. This invention is applicable to dynamic service recommendation and decision-making scenarios in dynamic service ecosystems, significantly improving the accuracy of API recommendations.

[0035] like Figure 1 As shown, the service recommendation decision-making method based on large model retrieval enhancement is applied to a service recommendation system, including the following steps:

[0036] S11. Obtain unstructured service requirements.

[0037] When users need to perform a specific task in a particular scenario, they often express their desired functional goals or technical requirements in natural language, such as "I need a map service that supports OAuth authentication and is compatible with mobile devices." Because such unstructured service requirements are flexible and often contain colloquial expressions, they are difficult to use directly for subsequent service matching. Therefore, they need to be processed to transform them into structured semantic expressions. The service requirement represents the user's functional need for a specific task, so that the service recommendation system can filter out a set of candidate services related to the service requirement based on its semantic understanding, and extract the corresponding APIs from these services for recommendation. In this application, a service refers to a functional unit with independent functionality that provides the ability to call functions through an API, used to meet functional requirements in a specific scenario.

[0038] S12. Call the large language model to perform semantic parsing and expansion on the service requirements, and generate unstructured extended semantic text.

[0039] As the initial preprocessing stage of the large language model-driven retrieval enhancement generation service decision recommendation framework, step S12 aims to enrich the semantic descriptions of service requirements and API documents. Traditional service requirements and API descriptions often suffer from issues such as inconsistencies in detail levels, missing technical specifications, and ambiguous classifications, severely impacting subsequent matching and recommendation performance. To improve this, semantic parsing and expansion of service requirements are necessary to ensure richer semantic expression and more accurate technical descriptions, facilitating subsequent matching with corresponding APIs. This application effectively bridges the semantic gap between natural language and technical documents by establishing a unified semantic expression space (converting text information from different sources and formats into structured and standardized semantic representations). Practical experience has verified its significant role in semantic consistency and technical accuracy, laying a solid foundation for subsequent service screening, interface matching, and recommendation inference.

[0040] Specifically, through a prompting engineering strategy, a large language model is used to semantically understand the service requests in natural language input by the user, identifying core functions, technical characteristics, application domains, and other technical constraints. Based on the identification results, a semantically coherent extended semantic text with standardized technical specifications is generated for subsequent service matching. It is understood that the large language model in this application is obtained through pre-training; the specific training process is not detailed here.

[0041] In an optional embodiment of the present invention, step S12 includes the following process:

[0042] First, the large language model is invoked to perform semantic parsing on the service requirements, generating semantic text.

[0043] The service requirements are input into a large language model. By semantically parsing the unstructured service requirements, the model identifies the core functions, operating platforms, and usage domains, and generates semantic text composed of multiple standardized fields. For example, if the service requirement is "I need a map service that supports OAuth authentication and is compatible with mobile devices," the semantic text could be "map service, OAuth authentication, mobile devices."

[0044] Then, the large language model is invoked again to perform semantic completion processing on the semantic text, generating extended semantic text with a unified expression style.

[0045] Based on semantic text, the language generation and knowledge reasoning capabilities of the large language model are used to expand and unify the expression of existing semantic elements, so as to generate an extended semantic text with complete semantic information and standardized expression style.

[0046] For example, a large language model can be invoked to rewrite the API. The prompt information (i.e., background description) input to the large language model is: You are an AI assistant specifically responsible for clarifying API descriptions and suggesting relevant tags. Your task is to enhance the API description by focusing on the core functions and features of the API, and suggest relevant additional tags while retaining existing tags. The raw input received by the large language model is a JSON object containing the following fields: {"title":"API name","description":"raw text description","tags":["tag1","tag2"]}, where title is the raw name of the API, description is the unstructured raw functional description, and tags are the pre-defined tag set for the API. During the description enhancement process, the following principles should be followed to ensure that the description is semantically clearer, more complete in content, and maintains a concise and professional technical language style: focus on the core functions and features of the API; specify supported platforms and interfaces; highlight key functions and use cases; describe integration methods; pay attention to special functions (such as localization); maintain technical accuracy; and maintain a concise writing style. In the tag processing stage, additional tags should be recommended based on the enhanced description content while retaining existing tags. Additional tags can come from the following five dimensions: core functionality, technical features, supported platforms, integration methods, and use cases. The output format of the large language model is: {"title":"original API name","enhanced_description":"a clear, structured description of the API","categories":["additional","related","tags"]}; where enhanced_description is the enhanced, standardized technical description, and categories is the complete set of tags given while retaining the original tags. Additional guidelines: Do not delete or modify existing categories; maintain the original title format; focus on technical accuracy and clarity; keep descriptions concise yet complete; ensure all suggested categories have descriptive basis.

[0047] As a concrete example, the content of the input large language model is {"title":"Google Maps API Master Record","description":"The Google Maps API allows external developers to embed Google Maps into web pages using a simple JavaScript interface or a Flash interface. It is designed for mobile devices and traditional desktop browser applications. The API includes localization, regional localization, and geocoding for more than 50 languages ​​and provides a mechanism for enterprise developers who want to use the Google Maps API on their intranet. Google Maps API Premier customers can access the API HTTP service via a secure (HTTPS) connection.","tags":["Map","Viewer"]}. The expected output is {"title":"Google Maps API Master Record","enhanced description":"A comprehensive map service API that supports embedding Google Maps functionality into web applications. Supports JavaScript and Flash interfaces for seamless integration on web and mobile platforms. Features include localization support for over 50 languages, region-specific mapping, and geocoding capabilities. Provides enterprise-grade features for Premier customers, supporting secure HTTPS access and intranet integration options.","categories":["Geolocation","Mobile","Enterprise","Localization","JavaScript","Integration"]}.

[0048] As another example, a large language model can be invoked for service rewriting. The prompt message (i.e., background description) input to the large language model is: You are an AI assistant specifically responsible for analyzing and improving service descriptions and categories. Your task is to improve the clarity of the service description while preserving and potentially expanding its categories. The original input received by the large language model is a JSON object containing the following fields: {"title": "Service Name", "description": "Original Service Description", "categories": ["Service Category 1", "Service Category 2"]}. The large language model is configured to perform description analysis: analyze the existing description and enhance its content, including: clearly explaining the main functions of the service; key features and capabilities; target users or use cases; any geographical or technical limitations; maintaining concise yet comprehensive wording; increasing technical clarity while preserving the original meaning; and including any implicit technical requirements. The requirements for handling categories in the large language model are as follows: All existing categories should be fully retained; additional relevant categories are recommended based on the following: core functionality (e.g., search, integration, visualization), technical components (e.g., API, data source), application domains (e.g., retail, social, finance), and user interaction types (e.g., search, browsing, analytics). The output of the large language model should be set as {"title":"Mashup Name","enhanced description":"Improved description, including technical details and clarity.","categories":["Additional","Related","Categories"]}. Additional guidelines are as follows: Maintain a professional tone by using clear technical language; avoid marketing language; be accurate and fact-based; enhance the description by focusing on the following: technical integration points; core functionality; user interaction flow; data sources and APIs; geographical aspects (e.g., relevance); real-time vs. static data processing; category recommendations should meet the following requirements: relevant to core functionality; reflect technical components; consider user interaction patterns; include industry-standard terminology; specific but not overly narrow. Important notes: Do not delete or modify existing categories; maintain the original title format; focus on technical accuracy and clarity; keep descriptions concise but complete; ensure all suggested categories have a descriptive basis.

[0049] As a concrete example, the input to the large language model is {"title":"Mashup:Krillion","description":"Shopping comparison service, focusing on local shopping. Search products nationwide and view inventory at nearby stores.","categories":["Map","E-commerce"]}. The expected output of the large language model is: {"title":"Mashup:Krillion","enhanced description":"A location-based shopping comparison service that integrates a national product database with a local store inventory system. This service allows users to search for products from multiple retailers and view real-time inventory at nearby physical stores. It combines geolocation services and retail inventory APIs to provide accurate, location-based shopping information and price comparisons.","categories":["Local Search","Retail","Geolocation","Price Comparison","Inventory Tracking"]}

[0050] S13. Encode the extended semantic text to obtain a semantic query vector.

[0051] In an optional embodiment of the present invention, step S13 includes the following process:

[0052] First, the extended semantic text is preprocessed to obtain the final extended semantic text.

[0053] In an optional embodiment of the present invention, the process of preprocessing the extended semantic text includes: segmenting the extended semantic text into sentences; removing stop words from the segmented extended semantic text to obtain the final extended semantic text. Specifically, the entire extended semantic text is segmented into several short sentences, and stop words are removed from each short sentence to obtain the final extended semantic text. Stop words include, but are not limited to, pre-defined structural particles, conjunctions, function words, and modal particles.

[0054] Then, the final extended semantic text is encoded to obtain the semantic query vector.

[0055] Extended semantic text in natural language form is encoded using a text encoding model. By capturing semantic features in the extended semantic text, it is mapped into a high-dimensional semantic vector, thus obtaining a semantic query vector. The text encoding model can be any embedding model capable of encoding text, including but not limited to models based on the Transformer architecture and OpenAI Embedding models pre-trained with large language models, etc., without limitation.

[0056] S14. Query the service description of each service from the service database, and calculate the first similarity score between the semantic query vector and the service description, and the second similarity score between each keyword in the extended semantic text and the service description, to obtain the comprehensive score of each service, and filter out a set of candidate services that are semantically related to the service requirements; wherein, the service description is used to characterize the functional characteristics of the corresponding service.

[0057] The system queries the service database for service descriptions, which characterize the functional features or applicable areas of the corresponding services. Based on these descriptions, relevant services associated with the user's service request can be filtered out. A first similarity score is calculated between the semantic query vector and each service description to measure the degree of association between the overall semantics of the service and its extended semantic text. Furthermore, a second similarity score is calculated between each keyword in the extended semantic text and each service description to measure the relevance of keywords to the service content. After obtaining the first and second similarity scores through this hybrid intelligent retrieval strategy, these scores are combined to calculate a comprehensive score for each service, thereby selecting a set of candidate services semantically related to the service request.

[0058] In an optional embodiment of the present invention, step S14 includes steps S141 to S146:

[0059] S141. Query the service description of each service from the service database.

[0060] The service database contains all the services, each with a corresponding service description. The service description can include the service's core functions, compatible platforms, supported protocol standards, and other related information, which is used to subsequently filter out services that match the user's service requirements.

[0061] For each service, execute steps S142 to S145:

[0062] S142. Encode the service description corresponding to the service to obtain the service description code.

[0063] The service description can be encoded using a text encoding model to obtain the service description code. Understandably, to speed up the recommendation process, all service descriptions in the service database can be pre-encoded, and a mapping relationship between the service description codes, corresponding service descriptions, and services can be established. This allows for direct retrieval of the corresponding service description code using the service's identifier information later.

[0064] S143. Calculate the cosine similarity between the semantic query vector and the service description encoding to obtain the first similarity score between the service and the service requirement.

[0065] For each service description code, the cosine similarity between the semantic query vector and the service description code is calculated to obtain the first similarity score between the service and the service requirement. Where sim(q,m) is the first similarity score between service demand q and service m, v q For semantic query vectors, v m Encoding the service description for service m, ||v q ‖ and ‖v m ‖ represent semantic query vector v q Service description encoding of service m v m The vector length is determined by the semantic query vector. Since the semantic query vector represents the user's intent obtained through extended semantic text encoding, while the service description encoding represents the semantic features of the service at the functional and technical levels, the first similarity score between the two can reflect the degree of matching between the service and the user's needs at the overall semantic level.

[0066] S144. Based on the BM25 algorithm, calculate the relevance score between each keyword in the extended semantic text and the service description corresponding to the service to obtain the second similarity score between the service and the service requirement.

[0067] To more comprehensively assess the correlation between service descriptions and service requirements, the BM25 algorithm is used to calculate a similarity score between each keyword and each service description. A second similarity score is obtained by summing the similarity scores of all keywords in the extended semantic text and the service descriptions of the same service. This score reflects the degree of matching between service content and requirement text at the keyword level and can be used together with the first similarity score for subsequent service filtering and ranking to make the filtering results more accurate.

[0068] In an optional embodiment of the present invention, step S144 includes the following processing procedure: for each keyword in the extended semantic text: calculate the relevance score between the keyword and the service description corresponding to the service. Where ws(w,m) is the relevance score between keyword w and service description of service m, f(w,m) is the frequency of keyword w in service description of service m, k1 and b are preset parameters, |m| is the length of service description, and agdl is the average length of all service descriptions; by summing the relevance scores between all keywords in the extended semantic text and the corresponding service descriptions, a second similarity score between the service and the service requirement is obtained.

[0069] Specifically, for each keyword w in the extended semantic text, the following process is performed: Calculate the relevance score between the keyword w and the service description of the current service m. By summing the relevance scores of all keywords in the extended semantic text, the second similarity score sore(q,m) between service m and service requirement q is obtained: sore(q,m) = ∑ w∈q ws(w,m). The second similarity score compensates for keyword information that may be missed in the overall semantic matching, thereby improving the coverage and accuracy of service retrieval.

[0070] S145. The first similarity score and the second similarity score are weighted and summed to obtain the comprehensive score of the service.

[0071] For each service m: its first similarity score and second similarity score are weighted and summed according to a preset weighting factor to obtain the comprehensive score of service m: final_sore(q,m) = α·sim(q,m) + β·score(q,m). Here, α and β are preset weighting factors (e.g., both preset to 0.5), and final_sore(q,m) is the comprehensive score of service m relative to service demand q. This comprehensive score integrates deep semantic analysis and global keyword matching, capturing both the functional relationships between APIs and ensuring comprehensive coverage of technical terms to improve the accuracy of subsequent recommendations.

[0072] S146. Sort all services according to their corresponding comprehensive scores, and select the services whose comprehensive scores are greater than the preset score threshold or whose comprehensive scores are among the top N as a set of candidate services; where N is a positive integer.

[0073] All services are sorted in descending order of their overall scores. Services with overall scores above a preset threshold are selected, or the top N services by overall score are chosen as the candidate service set. Because these selected services are highly relevant to the user's service requirements, the APIs subsequently selected will have higher accuracy.

[0074] S15. Determine all application programming interfaces (APIs) corresponding to the candidate service set, and based on the usage frequency of various APIs, their preset tags, and the semantic similarity between the semantic query vector, call the large language model to filter out the final set of APIs and make recommendations; wherein, each service corresponds to at least one API, and each API has at least one preset tag that characterizes its technical characteristics.

[0075] All corresponding APIs are extracted from the candidate service set to form a candidate application programming interface (API) set. The usage frequency of each API across all service calls is statistically analyzed to determine its generality. Furthermore, the semantic similarity between the API's pre-defined tags and semantic query vectors is calculated to determine the API's match with the current service requirements. By comprehensively evaluating these two aspects, a large language model is used to ultimately select and recommend a set of APIs that meet the current service requirements.

[0076] In an optional embodiment of the present invention, step S15 includes steps S151 to S155:

[0077] S151. Summarize all application programming interfaces corresponding to each service in the candidate service set to form a candidate application programming interface set; wherein, each service corresponds to at least one application programming interface.

[0078] The candidate service set is obtained by aggregating all APIs corresponding to each service in the candidate service set. Since each service corresponds to at least one API, and multiple services may share the same API, duplicate APIs may appear during the aggregation process, meaning that the same API may appear multiple times in the candidate service set.

[0079] S152. Calculate the usage frequency of each application programming interface in the candidate application programming interface set, arrange the various application programming interfaces in order based on the usage frequency, and select the top L application programming interfaces with the highest usage frequency to form the first target interface sequence; where L is a positive integer.

[0080] The set of candidate application programming interfaces S = {s1, s2, ..., s...} N Each API in} is s i Count the number of times each API appears in the entire candidate application programming interface set, and use this as the usage frequency. Sort all APIs in descending order of usage frequency, and select the L APIs with the highest usage frequency. Arrange them in descending order of their corresponding usage frequencies to form the first target interface sequence S. f .

[0081] S153. For each application programming interface in the candidate application programming interface set: determine its corresponding tag and calculate the semantic similarity between the tag and the semantic query vector.

[0082] For each API in the candidate application programming interface set, obtain its corresponding predefined tag and encode the tag into a tag vector. Calculate the semantic similarity between the tag and the semantic query vector. Where g(q,m) represents the semantic similarity between the label of service m and the service demand q, and t s The tag vector after encoding tag s, v q This is a semantic query vector.

[0083] S154. Sort all application programming interfaces (APIs) according to semantic similarity and select the top T APIs to form the second target interface sequence; where T is a positive integer.

[0084] All APIs in the candidate application programming interface set are sorted in descending order of semantic similarity between their corresponding tags and semantic query vectors. The top T APIs are then sorted in descending order of their corresponding semantic similarity to form the second target interface sequence S. g .

[0085] In an optional embodiment of the present invention, step S154 includes the following processing steps: sorting all application programming interfaces (APIs) according to semantic similarity to form a candidate interface sequence; sequentially selecting APIs from the candidate interface sequence, and performing the following process for each selected API: determining whether the API is not in the first target interface sequence; if so, adding the API to the second target interface sequence and continuing to select new APIs until the number of API types in the second target interface sequence reaches T or all APIs have been selected; wherein the initial state of the second target interface sequence is an empty set; otherwise, continuing to select new APIs until all APIs have been selected.

[0086] In this application, to improve the accuracy and coverage of API recommendations, a hybrid retrieval mechanism integrating semantic understanding capabilities and traditional information retrieval methods is proposed. Through a two-stage optimization ranking mechanism, reliable API combinations that frequently co-occur are prioritized based on API usage frequency. Furthermore, the candidate results are fine-grained by combining contextual semantic similarity, thereby identifying API combinations with genuine dependencies and eliminating semantic interference or invalid candidate APIs.

[0087] Specifically, all APIs are sorted in descending order of semantic similarity to form a candidate interface sequence. From this candidate interface sequence, one API is selected sequentially, and the following process is performed: It is determined whether the API is not in the previously obtained first target interface sequence. If the API is not in the first target interface sequence, it is directly added to the second target interface sequence, and the process continues with the next API until either of the following conditions is met to obtain a complete second target interface sequence: Condition 1: The number of API types in the second target interface sequence reaches a preset threshold T; Condition 2: All APIs in the candidate interface sequence have been traversed according to the above process. Conversely, if the current API is in the first target interface sequence, it is skipped, and the process continues with the next API until all APIs have been selected. It is understood that the initial state of the second target interface sequence is an empty set. This process supplements APIs that, although used less frequently, still have a certain relevance to the user's service needs, thereby improving the completeness of the recommendations.

[0088] S155. Summarize the first target interface sequence and the second target interface sequence, use the large language model to obtain the final application programming interface sequence and make recommendations.

[0089] Specifically, all APIs in the first and second target interface sequences are arranged sequentially to obtain the final application programming interface sequence. These final APIs comprehensively consider both the stability of interface usage and semantic matching, thereby ensuring that the recommended APIs are both technically practical and meet the functional and compatibility requirements of the current service needs.

[0090] In an optional embodiment of the present invention, step S155 includes steps S1551 to S1553:

[0091] S1551. Summarize the first target interface sequence and the second target interface sequence to form a candidate target interface sequence.

[0092] The APIs are sorted according to the order of the first target interface sequence and the second target interface sequence to form a candidate target interface sequence.

[0093] S1552. For each candidate target application programming interface in the candidate target interface sequence: based on the thinking chain reasoning strategy, call the large language model, and analyze the candidate target application programming interface based on the semantic query vector, all tags and service descriptions of the candidate target application programming interface, to determine whether the candidate target application programming interface is the final recommended interface.

[0094] In this application, a Chain of Thought (CoT) reasoning strategy is used to transform the decision-making and recommendation tasks into a structured reasoning problem, thereby generating the final recommended API. During this process, the large language model acts as a domain expert developer. The prompts input to the large language model provide basic context about the API ecosystem and service recommendations, guiding the model through a systematic reasoning process to progressively analyze the user's service requirements and technical constraints, ensuring high accuracy in both functional adaptability and technical compatibility of the final recommendation results. Specifically, for each candidate API in the candidate target interface sequence: a Chain of Thought (CoT) reasoning strategy is used, inputting the semantic query vector, all tags of the candidate API, and the service description of the corresponding service into the large language model, progressively analyzing whether the candidate API meets the core functionalities, technical protocols, deployment platform, and other requirements of the service needs. Furthermore, its interface compatibility and combination feasibility with other services are evaluated to determine whether the candidate API is the final recommended interface.

[0095] In an optional embodiment of the present invention, step S1552 includes the following processing procedure:

[0096] First, the semantic query vector, all tags and service descriptions of the candidate target application programming interface are input into the large language model, and structured reasoning is performed to obtain the adaptation conclusion of the candidate target application programming interface.

[0097] The semantic query vector, all tags and service descriptions of the candidate target application programming interface are jointly input into the large language model. The above information is analyzed through structured prompt design and mind chain reasoning strategy to obtain the adaptation conclusion of the API. The adaptation conclusion is used to characterize the capability features of the candidate target application programming interface.

[0098] Then, it is determined whether the adaptation conclusion meets the adaptation conditions set based on the service requirements: if it does, the candidate target application programming interface is taken as the final recommended interface; if it does not, the candidate target application programming interface is not the final recommended interface.

[0099] For each candidate API: determine if its adaptation result meets the adaptation conditions. If it does, the candidate API is selected as the final recommended interface. Otherwise, if it does not meet the conditions, the candidate API is excluded, and the next candidate API is selected for evaluation.

[0100] Furthermore, in an optional embodiment of the present invention, determining whether the adaptation conclusion meets the adaptation conditions set based on the service requirements includes the following processing steps:

[0101] First, the adaptation conclusions are analyzed to obtain the functional matching conclusions and technical compatibility conclusions.

[0102] The adaptation conclusions are structured and analyzed to extract functional matching and technical compatibility conclusions. The functional matching conclusions characterize whether the API supports the core functionalities required by the user. The technical compatibility conclusions characterize the API's technical suitability for the expected technical environment.

[0103] Then, it is determined whether the function matching conclusion meets the function matching conditions set by the service requirements, and whether the technology compatibility conclusion meets the interface compatibility requirements: if both meet, the adaptation conclusion meets the adaptation conditions set based on the service requirements; otherwise, the adaptation conclusion does not meet the adaptation conditions set based on the service requirements.

[0104] The system determines whether the function matching conclusion meets the function matching conditions set according to service requirements, such as whether it covers the target function module or supports the specified operation behavior. In addition, it also determines whether the technical compatibility conclusion meets interface compatibility requirements, such as support for specific platforms and communication protocols. If both of these conditions are met, the adaptation conclusion is deemed to meet the adaptation conditions; otherwise, it is deemed not to meet the adaptation conditions.

[0105] S1553. Summarize all the final recommended interfaces to form the final application programming interface sequence and make recommendations.

[0106] In an optional embodiment of the present invention, the process of selecting and recommending the final set of application programming interfaces (APIs) includes the following steps: generating a structured JSON object from the final set of APIs and then recommending it; wherein the JSON object includes the service requirements and the various APIs ultimately recommended.

[0107] In a specific example, based on the thought chain reasoning strategy, the reasoning method for using a large language model to determine whether a candidate target application programming interface (API) is the final recommended interface is as follows: First, the functional requirements are analyzed. The large language model carefully reads the user's service requirements and extracts the key functional requirements. Second, APIs are filtered: the description and tags of each API in all candidate target APIs are examined to determine whether they meet the extracted functional requirements, and only APIs that meet the requirements are retained. Then, for each retained API, its title field is extracted and included in the final output. Furthermore, to ensure the completeness of the recommendation results, it is also necessary to verify whether the selected APIs fully cover all functional requirements of the service. If a single API cannot meet all functions, multiple APIs can be combined to supplement the functions. The final sequence of application programming interfaces output by the large language model must contain exactly k items to serve as the recommendation result.

[0108] This application uses the ProgrammableWeb dataset for experiments, a widely used benchmark dataset in service recommendation research. After filtering out inactive services and unused APIs, the final dataset contains 6424 services, 1216 APIs, and 10778 call records. To discuss the performance level of the methods, ten methods were selected for comparison: NGCF (Graph Collaborative Filtering), T2L2 (Transformer-to-Label model for service text representation), TextCNN (Convolutional Neural Network architecture for text classification tasks), ServeNet (Deep Learning-based Service Recommendation Network), MTFM (Multi-Task Fusion Model), MGSR (Multi-Granularity Service Recommendation Method), SEHGN (Structured Augmented Hypergraph Neural Network), LLM Enhanced GNN (Method fusing large language models and graph neural networks), Native RAG (Standard Retrieval Augmentation Generation Method), Retrieval Only (Retrieval Only), and ServiceRAG(ours) (this application). Tables 1 and 2 show the evaluation results of all methods on the dataset. Where Recall@k represents the recall rate of the first k results in the recommendation list, Precious@k represents the precision rate of the first k results in the recommendation list, FI@k represents the F1 score of the first k results in the recommendation list, and NDCG@k represents the normalized depreciation cumulative gain of the first k results in the recommendation list.

[0109] Table 1 shows the recall and precision of each method in the first k results of the recommendation list.

[0110]

[0111] Table 2 shows the F1 scores and normalized depreciation cumulative gain of each method in the top k results of the recommendation list.

[0112]

[0113] Tables 1 and 2 clearly demonstrate the limitations of traditional methods in service recommendation. Traditional deep learning methods such as T2L2 (42.70% Recall@5), TextCNN (41.61% Recall@5), and ServeNet (43.35% Recall@5) perform relatively poorly, showing a significant gap compared to ServiceRAG (59.77% Recall@5). This significant performance gap empirically validates the view that traditional methods are inadequate in addressing the complex needs of service selection and development. The lower performance of these methods is attributed to their inability to capture the complex technical constraints and compatibility requirements crucial to service integration. Experimental results also provide strong evidence of the limitations of graph neural network (GNN)-based methods. As highlighted in this application, GNN methods face the challenge of potentially misleading co-occurrence patterns and difficulty in identifying genuine service dependencies. This is reflected in the performance of NGCF (25.19% Recall@5) and MGSR (41.88% Recall@5), which significantly lag behind ServiceRAG. NGCF performed poorly, indicating that purely graph-based methods have limitations in capturing real-world service relationships. SEHGN attempted to incorporate semantic information, which improved the results somewhat, but it was still insufficient (38.26% Recall@5), suggesting that simply adding semantic features to a graph-based model is not enough to address the complex needs of service recommendation.

[0114] The results validate the hypothesis of combining Large Language Models (LLMs) with Retrieval Augmentation Generation (RAG) for service recommendation. ServiceRAG's performance advantage remains consistent across different k values, showing significant improvements in both precision and recall. The higher precision at k=5 (19.77%, compared to 13.98% for T2L2) particularly demonstrates ServiceRAG's ability to make more accurate recommendations at the top of key positions, which is crucial for real-world service development scenarios. ServiceRAG significantly outperforms Native RAG (58.28% Recall@5) and retrieval-only methods (56.12% Recall@5), demonstrating the effectiveness of the proposed method. The significant improvement in NDCG@5 is particularly noteworthy, as it indicates ServiceRAG's stronger ability to rank relevant services higher. This aligns with the design goal of this application, which is to provide more accurate and context-relevant service recommendations by combining semantic understanding and structured retrieval of technical documents.

[0115] In the answer generation stage, this application compared the effectiveness of using thought chain reasoning with traditional generation methods, such as... Figure 2 As shown, Metric is the x-axis, Relative Performance is the y-axis, w-COT represents the result using the thought chain inference strategy, and w / o COT represents the result without using the thought chain strategy. Experimental results show that the thought chain-based prompting method significantly outperforms conventional methods in terms of recall, precision (P), F1 score (F1), and normalized depreciation cumulative gain (NDCG). This demonstrates that task modeling enables large language models to understand the functional requirements and technical constraints of system inference services from the perspective of domain experts, under explicit instruction guidance, thereby achieving a deep understanding of the needs and ultimately generating more accurate service decision recommendations.

[0116] To evaluate the impact of API ranking strategies on recommendation performance, this application compared its proposed scheme with three other different API ranking schemes within the ServiceRAG framework. The results are shown in Table 3. As can be seen from the table, API ranking based on usage frequency significantly improved recommendation performance, increasing recall from 61.16% to 68.11%, validating the positive effect of API usage frequency on recommendation accuracy. It is worth noting that re-ranking based solely on semantic similarity was slightly less effective than the baseline (recall decreased from 61.16% to 58.82%). However, when usage frequency and semantic similarity were combined, recommendation performance was further optimized (recall increased to 68.21%). This indicates that although semantic similarity alone has limited effectiveness, when combined with high usage frequency, APIs that highly match the target Mashup category in terms of functional tags can still effectively meet the requirements.

[0117] Table 3 Ablation Experiment Results Regarding the Ranking Method

[0118]

[0119] like Figure 3As shown, the service recommendation decision system 300 based on large-scale model retrieval enhancement includes: a service requirement acquisition module 310, a semantic parsing module 320, an encoding module 330, a service matching module 340, and an interface filtering module 350. The service requirement acquisition module 310 acquires unstructured service requirements. The semantic parsing module 320 calls a large language model to perform semantic parsing and expansion on the service requirements, generating unstructured expanded semantic text. The encoding module 330 encodes the expanded semantic text to obtain a semantic query vector. The service matching module 340 queries pre-stored service descriptions from a service database, calculates a first similarity score between the semantic query vector and the service description, and a second similarity score between each keyword in the expanded semantic text and the service description, obtaining a comprehensive score for each service, and thereby filtering out a set of candidate services semantically related to the service requirements; wherein, the service description is used to characterize the functional characteristics of the corresponding service. The interface filtering module 350 is used to determine all application programming interfaces (APIs) corresponding to the candidate service set. Based on the usage frequency of various APIs, their preset tags, and the semantic similarity between them and the semantic query vector, the module calls the large language model to filter out the final set of APIs and make recommendations. Each service corresponds to at least one API, and each API has at least one preset tag that characterizes its technical features.

[0120] Specific limitations regarding the service recommendation decision-making system based on large-model retrieval enhancement can be found in the limitations of the service recommendation decision-making method based on large-model retrieval enhancement mentioned above, and will not be repeated here. Each module in the aforementioned service recommendation decision-making system based on large-model retrieval enhancement can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware format, or stored in the memory of a computer device in software format, so that the processor can call the corresponding operations of each module.

[0121] It should be noted that, in order to highlight the innovative aspects of this invention, this embodiment does not include modules that are not closely related to solving the technical problems proposed by this invention, but this does not mean that there are no other modules in this embodiment.

[0122] like Figure 4 As shown, electronic device 4 may include memory 41, processor 42 and bus, and may also include computer programs stored in memory 41 and executable on processor 42, such as service recommendation decision-making programs based on large model retrieval enhancement generation.

[0123] The memory 41 includes at least one type of readable storage medium, including flash memory, portable hard drive, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 41 can be an internal storage unit of the electronic device 4, such as a portable hard drive. In other embodiments, the memory 41 can be an external storage device of the electronic device 4, such as a plug-in portable hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 4. Furthermore, the memory 41 can include both internal and external storage units of the electronic device 4. The memory 41 can be used not only to store application software and various types of data installed on the electronic device 4, such as code for service recommendation decisions generated based on large model retrieval enhancement, but also to temporarily store data that has been output or will be output.

[0124] In some embodiments, the processor 42 may be composed of integrated circuits, such as a single packaged integrated circuit or multiple integrated circuits packaged with the same or different functions, including combinations of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The processor 42 is the control unit of the electronic device 4, connecting various components of the electronic device 4 through various interfaces and lines. It executes programs or modules stored in the memory 41 (such as recommended programs from application programming interfaces) and calls data stored in the memory 41 to perform various functions and process data in the electronic device 4.

[0125] Processor 42 executes the operating system of electronic device 4 and various installed applications. Processor 42 executes applications to implement the steps in the service recommendation decision-making method based on large model retrieval enhancement described above.

[0126] For example, a computer program can be divided into one or more modules, one or more of which are stored in memory 41 and executed by processor 42 to complete this application. One or more modules can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in electronic device 4. For example, the computer program can be divided into a service request acquisition module 310, a semantic parsing module 320, an encoding module 330, a service matching module 340, and an interface filtering module 350.

[0127] The integrated unit implemented as a software functional module described above can be stored in a computer-readable storage medium, which can be non-volatile or volatile. The software functional module stored in the storage medium includes several instructions to cause a computer device (which may be a personal computer, computer equipment, or network device, etc.) or processor to execute some functions of the service recommendation decision-making method based on large model retrieval enhancement in the various embodiments of this application.

[0128] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A service recommendation decision-making method based on large model retrieval enhancement generation, characterized in that, The method includes: Obtain unstructured service requirements; The large language model is invoked to perform semantic parsing and expansion on the service requirements, generating unstructured extended semantic text; The extended semantic text is encoded to obtain a semantic query vector; The service descriptions of each pre-stored service are queried from the service database, and the first similarity score between the semantic query vector and the service description, as well as the second similarity score between each keyword in the extended semantic text and the service description, are calculated to obtain the comprehensive score of each service. Based on this, a set of candidate services that are semantically related to the service requirements is selected; wherein, the service description is used to characterize the functional characteristics of the corresponding service. All application programming interfaces (APIs) corresponding to the candidate service set are determined. Based on the usage frequency of various APIs, their preset tags, and the semantic similarity between them and the semantic query vector, the large language model is invoked to filter out the final set of APIs and make recommendations. Each service corresponds to at least one API, and each API has at least one preset tag that characterizes its technical characteristics. The process of determining all application programming interfaces (APIs) corresponding to the candidate service set, based on the usage frequency of various APIs, their preset tags, and the semantic similarity between the semantic query vector, and then using the large language model to filter out the final set of APIs and make recommendations, includes: The application programming interfaces (APIs) corresponding to each service in the candidate service set are aggregated to form a candidate API set; wherein each service corresponds to at least one API. The frequency of use of each application programming interface (API) in the candidate API set is statistically analyzed. Based on the frequency of use, the APIs are arranged in order, and the top L APIs with the highest frequency of use are selected to form the first target interface sequence; where L is a positive integer. For each application programming interface in the candidate application programming interface set: determine its corresponding tag and calculate the semantic similarity between the tag and the semantic query vector; All application programming interfaces (APIs) are sorted according to semantic similarity, and the top T APIs are selected to form the second target interface sequence; where T is a positive integer. The first target interface sequence and the second target interface sequence are summarized, and the large language model is called to obtain the final application programming interface sequence and make a recommendation.

2. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 1, characterized in that, The process of calling a large language model to perform semantic parsing and expansion on the service requirements, generating unstructured extended semantic text, includes: The large language model is invoked to perform semantic parsing on the service requirements, generating semantic text. The large language model is invoked again to perform semantic completion processing on the semantic text, generating extended semantic text with a unified expression style.

3. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 1, characterized in that, The process of encoding the extended semantic text to obtain a semantic query vector includes: The extended semantic text is preprocessed to obtain the final extended semantic text; The final extended semantic text is encoded to obtain a semantic query vector.

4. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 3, characterized in that, The preprocessing of the extended semantic text to obtain the final extended semantic text includes: The extended semantic text is segmented into sentences; Stop words are removed from the extended semantic text after sentence segmentation to obtain the final extended semantic text.

5. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 1, characterized in that, The process involves querying the pre-stored service description codes of each service from the service database, calculating the first similarity score between the semantic query vector and the service description, and the second similarity score between each keyword in the extended semantic text and the service description, to obtain a comprehensive score for each service. Based on this score, a set of candidate services semantically related to the service requirement is selected, including: Retrieve the service descriptions of each service from the service database; For each service: The service description corresponding to this service is encoded to obtain the service description code; Calculate the cosine similarity between the semantic query vector and the service description encoding to obtain the first similarity score; Based on the BM25 algorithm, the relevance score between each keyword in the extended semantic text and the service description corresponding to the service is calculated to obtain the second similarity score. The first similarity score and the second similarity score are weighted and summed to obtain the overall score of the service; All services are sorted according to their corresponding comprehensive scores, and those with comprehensive scores greater than a preset score threshold or those ranking in the top N are selected as a candidate service set; where N is a positive integer.

6. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 5, characterized in that, The BM25 algorithm is used to calculate the relevance score between each keyword in the extended semantic text and the service description corresponding to the service, resulting in a second similarity score, including: For each keyword in the extended semantic text: calculate the relevance score between the keyword and the service description corresponding to the service. ,in, Keywords The relevance score between the service description of service m and service m. Keywords Frequency in the service description of service m and These are preset parameters. For the length of the service description, The average length of all service descriptions; The relevance scores between all keywords in the extended semantic text and the corresponding service description are summarized to obtain the second similarity score.

7. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 1, characterized in that, The step of sorting all application programming interfaces (APIs) based on semantic similarity and selecting the top T APIs to form the second target interface sequence includes: All application programming interfaces are sorted according to semantic similarity to form a candidate interface sequence; Application programming interfaces are selected sequentially from the candidate interface sequence, and for each selected application programming interface: Determine whether the application programming interface is not in the first target interface sequence: If so, the application programming interface is added to the second target interface sequence, and new application programming interfaces are selected until the number of application programming interfaces in the second target interface sequence reaches T or all application programming interfaces have been selected; wherein, the initial state of the second target interface sequence is an empty set; Otherwise, continue selecting new application programming interfaces (APIs) until all APIs have been selected.

8. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 1, characterized in that, The process of summarizing the first target interface sequence and the second target interface sequence to obtain the final application programming interface sequence and making a recommendation includes: The first target interface sequence and the second target interface sequence are combined to form a candidate target interface sequence; For each candidate target application programming interface in the candidate target interface sequence: based on the thinking chain reasoning strategy, the large language model is invoked, and the candidate target application programming interface is analyzed based on the semantic query vector, all tags and service descriptions of the candidate target application programming interface, to determine whether the candidate target application programming interface is the final recommended interface; All the final recommended interfaces are compiled to form the final application programming interface sequence and then recommended.

9. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 8, characterized in that, The reasoning strategy based on the thought chain invokes the large language model to analyze the candidate target application programming interface (API) based on the semantic query vector and all tags and service descriptions of the API, determining whether the API is the final recommended interface, including: The semantic query vector and all tags and service descriptions of the candidate target application programming interface are input into the large language model, and structured reasoning is performed to obtain the adaptation conclusion of the candidate target application programming interface. Determine whether the adaptation conclusion meets the adaptation conditions set based on the service requirements: If it meets the criteria, the candidate target application programming interface will be used as the final recommended interface. If it does not meet the requirements, then the candidate target application programming interface is not the final recommended interface.

10. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 9, characterized in that, The determination of whether the adaptation conclusion meets the adaptation conditions set based on the service requirements includes: The adaptation conclusions are analyzed to obtain the functional matching conclusions and technical compatibility conclusions. Determine whether the function matching conclusion meets the function matching conditions set for the service requirements, and whether the technology compatibility conclusion meets the interface compatibility requirements; If all conditions are met, the adaptation conclusion meets the adaptation conditions set based on the service requirements. Otherwise, the adaptation conclusion does not meet the adaptation conditions set based on the service requirements.

11. The service recommendation decision-making method based on large model retrieval enhancement generation according to claim 1, characterized in that, The step of selecting and recommending the final set of application programming interfaces (APIs) includes: generating a structured JSON object from the final set of APIs and recommending it; wherein the JSON object includes the service requirements and the various APIs ultimately recommended.

12. A service recommendation decision-making system based on large model retrieval enhancement generation, characterized in that, The system includes: The service requirement retrieval module is used to retrieve unstructured service requirements. The semantic parsing module is used to call the large language model to perform semantic parsing and expansion on the service requirements, and generate unstructured extended semantic text; The encoding module is used to encode the extended semantic text to obtain a semantic query vector; The service matching module is used to query the service descriptions of each pre-stored service from the service database, and calculate the first similarity score between the semantic query vector and the service description, as well as the second similarity score between each keyword in the extended semantic text and the service description, to obtain the comprehensive score of each service, and thereby filter out a set of candidate services that are semantically related to the service requirements; wherein, the service description is used to characterize the functional characteristics of the corresponding service. The interface filtering module is used to determine all application programming interfaces (APIs) corresponding to the candidate service set, and based on the usage frequency of various APIs, their preset tags, and the semantic similarity between the semantic query vector, it calls the large language model to filter out the final set of APIs and make recommendations; wherein, each service corresponds to at least one API, and each API has at least one preset tag that characterizes its technical characteristics. The process of determining all application programming interfaces (APIs) corresponding to the candidate service set, based on the usage frequency of various APIs, their preset tags, and the semantic similarity between the semantic query vector, and then using the large language model to filter out the final set of APIs and make recommendations, includes: The application programming interfaces (APIs) corresponding to each service in the candidate service set are aggregated to form a candidate API set; wherein each service corresponds to at least one API. The frequency of use of each application programming interface (API) in the candidate API set is statistically analyzed. Based on the frequency of use, the APIs are arranged in order, and the top L APIs with the highest frequency of use are selected to form the first target interface sequence; where L is a positive integer. For each application programming interface in the candidate application programming interface set: determine its corresponding tag and calculate the semantic similarity between the tag and the semantic query vector; All application programming interfaces (APIs) are sorted according to semantic similarity, and the top T APIs are selected to form the second target interface sequence; where T is a positive integer. The first target interface sequence and the second target interface sequence are summarized, and the large language model is called to obtain the final application programming interface sequence and make a recommendation.

13. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the service recommendation decision method based on large model retrieval enhancement as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the computer's processor, causes the computer to perform the service recommendation decision-making method based on large model retrieval enhancement as described in any one of claims 1 to 11.

Images