Service recommendation decision-making method based on large model retrieval enhancement generation and related equipment

Abstract

The invention provides a service recommendation decision-making method based on large model retrieval enhancement generation and related equipment. The method comprises the following steps: acquiring an unstructured service demand; calling a large language model to perform semantic analysis and extension on the service demand, and generating an unstructured extended semantic text; encoding the extended semantic text to obtain a semantic query vector; querying a service description of each pre-stored service from a service database, respectively calculating a first similarity score between the semantic query vector and the service description, expanding a second similarity score between each keyword in the semantic text and the service description, and screening out a candidate service set having semantic association with the service demand; all corresponding application programming interfaces in the candidate service set are determined, and a final application programming interface set is screened out and recommended according to the use frequency of the various application programming interfaces, the semantic similarity among the labels and the semantic query vectors. According to the method and the device, the API recommendation accuracy is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of service recommendation, and in particular to a service recommendation decision method based on large model retrieval enhancement generation and related equipment. BACKGROUND

[0002] Service recommendation decision systems are becoming increasingly important in today's digital ecosystem, which refers to an intelligent system that automatically recommends appropriate API combinations to developers based on user input requirements, taking into account factors such as compatibility, dependency relationships, and technical adaptability between various Application Programming Interfaces (APIs).

[0003] Because service recommendation not only needs to fully understand the user's natural language requirements, but also needs to consider whether each API can be used together in terms of interface compatibility, technical dependency, etc. Traditional recommendation methods (such as collaborative filtering, content-based matching, or graph-based analysis) have been proven to be effective ways in product recommendation, but in service recommendation tasks, it is often difficult to identify and handle these complex technical associations, resulting in inaccurate recommendations of related APIs based on user requirements. In addition, these traditional recommendation methods require a large amount of historical data for analysis and decision-making, and once new APIs are released or APIs are frequently updated, the accuracy of the recommendations will be significantly reduced. Therefore, a service recommendation decision method based on large model retrieval enhancement generation and related equipment is needed. SUMMARY

[0004] The present application provides a service recommendation decision method based on large model retrieval enhancement generation to improve the technical problem that the existing technology cannot fully consider the technical compatibility between each API when recommending APIs, resulting in poor accuracy of recommendations.

[0005] The application provides a service recommendation decision method based on large model retrieval and enhanced generation, which 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, and a second similarity score between each keyword in the expanded semantic text and the service description, obtaining a comprehensive score of each service, and screening out a candidate service set having semantic correlation with the service demand according to the comprehensive score; wherein the service description is used to represent the functional characteristics of the corresponding service; determining all application programming interfaces in the candidate service set, screening out a final application programming interface set according to the use frequency of various application programming interfaces, the semantic similarity between the preset labels of the application programming interfaces and the semantic query vector, and calling the large language model to recommend the final application programming interface set; wherein each service corresponds to at least one application programming interface, and each application programming interface is preset with at least one label representing the technical characteristics thereof.

[0006] In an embodiment of the application, the calling of the large language model to perform semantic analysis and expansion on the service demand to generate unstructured expanded semantic text comprises: calling the large language model to perform semantic analysis on the service demand to generate semantic text; and calling the large language model again to perform semantic completion processing on the semantic text to generate expanded semantic text with a unified expression style.

[0007] In an embodiment of the application, the encoding of the expanded semantic text to obtain a semantic query vector comprises: preprocessing the expanded semantic text to obtain final expanded semantic text; and encoding the final expanded semantic text to obtain a semantic query vector.

[0008] In an embodiment of the application, the preprocessing of the expanded semantic text to obtain final expanded semantic text comprises: performing sentence segmentation processing on the expanded semantic text; and removing stop words in the segmented expanded semantic text to obtain final expanded semantic text.

[0009] In an embodiment of the present application, the method for screening candidate services with semantic relevance to the service demand based on the service database comprises the following steps: querying the service description 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 the first similarity score between the service and the service demand; 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 between the service and the service demand; and weighting and summing the first similarity score and the second similarity score to obtain the comprehensive score of the service.

[0010] In an embodiment of the present application, the method for 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 comprises the following steps: for each keyword in the extended semantic text, calculating the relevance score between the keyword and the service description corresponding to the service wherein ws(w, m) is the relevance score between the keyword w and the service description of the service m, f(w, m) is the frequency of the keyword w in the service description of the service m, k1 and b are preset parameters, |m| is the length of the service description, and agdl is the average length of all service descriptions; and the relevance scores between all keywords in the extended semantic text and the service description corresponding to the service are aggregated to obtain the second similarity score between the service and the service demand.

[0011] In an embodiment of the present application, the determining all application programming interfaces corresponding to each service in the candidate service set according to the frequency of use of each application programming interface, the semantic similarity between the label corresponding to each application programming interface and the semantic query vector, and calling the large language model to filter and recommend a final application programming interface set comprises: aggregating 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; counting the frequency of use of each application programming interface in the candidate application programming interface set, sequentially arranging each application programming interface based on the frequency of use, and selecting the top L application programming interfaces with the highest frequency of use to form a first target interface sequence; wherein L is a positive integer; for each application programming interface in the candidate application programming interface set: determining the label corresponding to the application programming interface and calculating the semantic similarity between the label and the semantic query vector; arranging all application programming interfaces according to the semantic similarity and selecting the top T application programming interfaces to form a second target interface sequence; wherein T is a positive integer; aggregating the first target interface sequence and the second target interface sequence and calling the large language model to obtain a final application programming interface sequence and recommend it.

[0012] In an embodiment of the present application, the arranging all application programming interfaces according to the semantic similarity and selecting the top T application programming interfaces as a second target interface sequence comprises: arranging all application programming interfaces according to the semantic similarity to form a candidate interface sequence; sequentially selecting application programming interfaces from the candidate interface sequence, and for each selected application programming interface: determining whether the application programming interface is not in the first target interface sequence; if yes, adding the application programming interface to the second target interface sequence and continuing to select a new application programming interface until the number of application programming interfaces in the second target interface sequence reaches T or all application programming interfaces are selected; wherein the initial state of the second target interface sequence is an empty set; otherwise, continue to select a new application programming interface until all application programming interfaces are selected.

[0013] In an embodiment of the present application, the first target interface sequence and the second target interface sequence are aggregated, and the large language model is called to obtain a final application programming interface sequence and make a recommendation, which includes: aggregating 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 a thinking chain reasoning strategy, calling the large language model to analyze the candidate target application programming interface based on the semantic query vector, all labels and service descriptions of the candidate target application programming interface, and determining whether the candidate target application programming interface is a final recommended interface; aggregating all final recommended interfaces to form a final application programming interface sequence and make a recommendation.

[0014] In an embodiment of the present application, based on the thinking chain reasoning strategy, the large language model is called to analyze the candidate target application programming interface based on the semantic query vector, the label and the service description of the candidate target application programming interface, and determine whether the candidate target application programming interface is a final recommended interface, which includes: inputting the semantic query vector, all labels and service descriptions of the candidate target application programming interface into the large language model to perform structured reasoning to obtain an adaptation conclusion of the candidate target application programming interface; determining whether the adaptation conclusion meets the adaptation conditions set based on the service demand: if yes, the candidate target application programming interface is taken as a final recommended interface; if not, the candidate target application programming interface is not a final recommended interface.

[0015] In an embodiment of the present application, determining whether the adaptation conclusion meets the adaptation conditions set based on the service demand includes: analyzing the adaptation conclusion to obtain a function matching conclusion and a technical compatibility conclusion in the adaptation conclusion; determining whether the function matching conclusion meets the function matching conditions set by the service demand 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 demand; otherwise, the adaptation conclusion does not meet the adaptation conditions set based on the service demand.

[0016] In an embodiment of the present application, the final application programming interface set is screened out and recommended, which includes: generating a structured JSON object from the final application programming interface set and making a recommendation; wherein the JSON object includes the service demand and various final recommended application programming interfaces.

[0017] The application further provides a service recommendation decision system based on large model retrieval and enhanced generation, which comprises: a service demand acquisition module, which is used for acquiring unstructured service demand; a semantic analysis module, which is used for calling a large language model to perform semantic analysis and expansion on the service demand, and generating unstructured expanded semantic text; an encoding module, which is used for encoding the expanded semantic text to obtain a semantic query vector; a service matching module, which is used for querying pre-stored service descriptions of various services from a service database, respectively calculating a first similarity score between the semantic query vector and the service description, and a second similarity score between various keywords in the expanded semantic text and the service description, obtaining a comprehensive score of each service, and screening out a candidate service set having semantic correlation with the service demand according to the comprehensive score; wherein the service description is used for representing the functional characteristics of the corresponding service; and an interface screening module, which is used for determining all application programming interfaces corresponding to the candidate service set, screening out a final application programming interface set according to the use frequency of various application programming interfaces, the semantic similarity between the pre-set labels of the application programming interfaces and the semantic query vector, and calling the large language model to recommend the final application programming interface set; wherein each service corresponds to at least one application programming interface, and each application programming interface is pre-set with at least one label representing the technical characteristics thereof.

[0018] The application further provides an electronic device, which comprises: one or more processors; and a storage device, which is used for storing one or more programs, and causes the electronic device to implement the service recommendation decision method based on large model retrieval and enhanced generation according to any one of the above aspects when the one or more programs are executed by the one or more processors.

[0019] The application further provides a computer-readable storage medium, which stores a computer program, and causes a computer to execute the service recommendation decision method based on large model retrieval and enhanced generation according to any one of the above aspects when the computer program is executed by a processor of the computer.

[0020] The application has the following beneficial effects: the service recommendation decision method based on large model retrieval and enhanced generation and the related device provided by the application generate expanded semantic text in a unified style by introducing a large language model to perform semantic analysis and expansion on unstructured service demand. The pre-stored services are screened through a double similarity calculation strategy to obtain a candidate service set having a high correlation degree with the service demand of a user. The API recommendation result conforming to the user demand is screened by combining the API information associated with the service, comprehensively considering the use frequency of the interface, the label characteristics and the matching degree of the service demand. The application is suitable for service dynamic recommendation and decision scenarios in a dynamic service ecosystem, and significantly improves the accuracy of API recommendation. BRIEF DESCRIPTION OF DRAWINGS

[0021] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the application. It is to be understood that the drawings are designed solely for purposes of illustration to be used in conjunction with the description in

[0022] In the drawings:

[0023] Figure 1 A flowchart of a service recommendation decision method based on large model retrieval enhanced generation provided by an embodiment of the present application is shown in the figure.

[0024] Figure 2 A comparison column chart of experimental results of different methods is shown in the figure.

[0025] Figure 3 A structural block diagram of a service recommendation decision system based on large model retrieval enhanced generation provided by an embodiment of the present application is shown in the figure.

[0026] Figure 4 A structural diagram of an electronic device provided by an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0027] The above and other advantages and features of the present application will become apparent from the following description of the embodiments, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the application. This description is given for the sake of example and the details are not intended to limit the present application. The present application can be implemented in other specific forms without departing from the spirit or essential characteristics thereof. The exemplary embodiments are disclosed along with specific details in order to provide a thorough understanding thereof. However, the present application can be implemented and used without employing some or all of the specific details provided herein.

[0028] It should be noted that the drawings provided in the following embodiments are only to illustrate the basic concept of the present application in a schematic manner, and the drawings only show the components related to the present application, not the number, shape and size of the components when actually implemented. The actual implementation of each component may be randomly changed in shape, number and proportion, and the layout pattern of the components may be more complex.

[0029] In the following description, numerous specific details are discussed in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to one of ordinary skill in the art that the embodiments of the present application can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the embodiments of the present application.

[0030] The inventors find that, since service combination recommendation not only needs to understand the independent ability of each service, but also must model the interaction mechanism between services, dependency relationship and the overall efficiency of their cooperation in completing tasks, the technical difficulty of service combination recommendation is more obvious than that of traditional product recommendation tasks. Therefore, in the current dynamic evolving service environment, traditional service recommendation systems (such as collaborative filtering, content-based matching or graph neural network-based) are insufficient. This is because as services continue to introduce new features, release new versions or be abandoned, service recommendation systems must have a deep understanding of the context and accurate judgment of technical compatibility between services, especially when the goal of service recommendation is no longer the selection of a single service, but to recommend a group of services that can cooperate to meet complex application requirements. At this time, the existing service recommendation system often cannot accurately recommend the corresponding API combination.

[0031] Over the past decade, service recommendation methodologies have undergone significant evolution. Early methods were represented by Collaborative Filtering (CF), which made recommendations based on successful service combinations and usage patterns in history. Although CF performs well in simple scenarios, it has a cold start problem when facing new services, and it is difficult to handle complex technical constraints involved in service combination. Content-Based Filtering attempts to make up for this deficiency by analyzing service descriptions and API specifications, but it still has obvious shortcomings in semantic understanding and service interoperability.

[0032] To overcome these limitations, existing service recommendation systems mostly use Graph Neural Network (GNN) methods to model the service ecosystem as a multi-node, multi-relation graph structure. Such methods capture the potential relationships and compatibility patterns between services by constructing a service co-occurrence graph. However, GNN methods still face multiple challenges: on the one hand, the co-occurrence graph contains a large amount of noise, affecting the accuracy of reasoning; on the other hand, although GNN has the ability to model complex relationships, it is difficult to accurately identify the truly key dependency relationships and interaction patterns in the service integration process. In addition, like traditional methods, GNN still needs to frequently retrain the model when facing the dynamic environment of frequent service evolution and continuous introduction of new services, making it difficult to adapt to the rapidly changing and iterating service ecosystem.

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

[0034] In order to improve the above problems and combine the relationship between the large language model and the retrieval enhancement generation framework discovered by the inventor, the present invention provides a service recommendation decision method based on large model retrieval enhancement generation, which introduces a large language model to perform semantic analysis and expansion on unstructured service requirements to generate extended semantic text in a unified style. The pre-stored services are screened through a dual similarity calculation strategy to obtain a set of candidate services with a high correlation with the user's service needs. In combination with the API information associated with the service, the frequency of interface use, the degree of matching of label characteristics and service requirements are comprehensively considered to screen out API recommendation results that meet user needs. The present invention is applicable to dynamic service recommendation and decision-making scenarios in dynamic service ecosystems, and significantly improves the accuracy of API recommendations.

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

[0036] S11. Obtain unstructured service requirements.

[0037] When a certain task in a specific scenario needs to be performed, the user often expresses the functional goal or technical requirement in the form of natural language, such as "I need a map service that supports OAuth authentication and is compatible with mobile terminals". Due to the flexible and variable characteristics of such unstructured service requirements, and often containing some colloquial expressions, it is difficult to directly use them for subsequent service matching, so it is necessary to convert them into structured semantic expressions through related processing. Among them, the service requirement is used to represent the functional appeal of the user to a certain task, so that the service recommendation system can filter out a set of candidate services related to the service requirement according to the semantic understanding of the service requirement, and recommend the corresponding API from these services. Among them, the service of the present application refers to a functional unit that has independent functions and provides calling ability to the outside through API, which is used to meet the functional requirements in a specific scenario.

[0038] S12, calling a large language model to perform semantic analysis and expansion on the service requirement to generate an unstructured expanded semantic text.

[0039] As the initial preprocessing stage of the retrieval enhancement generation service decision recommendation framework driven by the large language model, step S12 aims to enrich the semantic description of the service requirement and API document. Because the traditional service requirement and API description usually have problems such as inconsistent detail levels, missing technical specifications, and fuzzy classification, which seriously affect the subsequent matching and recommendation effect. In order to improve this problem, the service requirement needs to be semantically analyzed and expanded to ensure that the service requirement is more rich in semantic expression and more accurate in technical description, so as to match the corresponding API later. The present application effectively bridges the semantic gap between natural language and technical documents by establishing a unified semantic expression space (i.e. converting text information of different sources and formats into structured and standardized semantic representations), and verifies its significant role in semantic consistency and technical accuracy in practice, laying a solid foundation for subsequent service screening, interface matching and recommendation reasoning.

[0040] Specifically, by using the large language model to perform semantic understanding on the service requirement input by the user in the form of natural language, the core function, technical characteristics, use domain and other technical constraint information in the service requirement are identified, and an expanded semantic text with semantic coherence and standardized technical specification expression is generated based on the identification result, so as to be used for subsequent service matching. It can be understood that the large language model of the present application is obtained by pre-training, and the specific training process is not described in detail.

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

[0042] First, the large language model is called to perform semantic analysis on the service requirement to generate a semantic text.

[0043] The service requirement is input into a large language model, the core function, running platform, use field and other technical constraint information in the unstructured service requirement are identified through semantic analysis, and a semantic text composed of multiple standardized fields is generated accordingly. Illustratively, the service requirement is "I need a map service supporting OAuth authentication and compatible with mobile terminal", and the semantic text can be "map service, OAuth authentication, mobile terminal".

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

[0045] On the basis of the semantic text, the existing semantic elements are extended and uniformly expressed through the language generation and knowledge reasoning capabilities of the large language model, so as to generate an extended semantic text with complete semantic information and a standardized expression style.

[0046] Exemplarily, the large language model can be called for API rewriting, and the prompt information (i.e., background description) input to the large language model is: you are an AI assistant specializing in 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 the existing tags. The original input received by the large language model is a JSON object containing the following fields: {"title":"API name", "description":"original description text", "tags":["tag1", "tag2"]}, where title is the original name of the API, description is the unstructured original function description, and tags is the preset tag set of the API. In the process of enhancing the description, 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 the supported platforms and interfaces; highlight key functions and use cases; describe integration methods; pay attention to special functions (such as localization); maintain technical accuracy; maintain a concise writing style. In the tag processing stage, additional tags should be recommended based on the enhanced description content while retaining the existing tags. Additional tags can come from the following five dimensions: core functions, technical features, supported platforms, integration methods, and use areas. The output format of the large language model is: {"title":"original API name", "enhanced_description":"clear and structured description of the API", "categories":["additional", "relevant", "tags"]} ; where enhanced_description is the enhanced standardized technical description, and categories is the complete tag set given based on retaining the original tags. Additional guidelines: do not delete or modify existing categories; maintain the original title format; focus on technical accuracy and clarity; maintain a concise but complete description; ensure that all suggested categories have a description basis.

[0047] As a specific example, the input to the large language model is {“title”:“Google Maps API main record”,“description”:“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 in over 50 languages, regional localization, and geocoding, and provides mechanisms for enterprise developers who want to use the Google Maps API within their intranet. Google Maps API Premier customers can access the API HTTP service through secure (HTTPS) connections.”,“tags”:[“maps”,“viewer”]}. The expected output is {“title”:“Google Maps API main record”,“enhanced description”:“A comprehensive mapping service API that enables embedding Google Maps functionality into web applications. Supports both JavaScript and Flash interfaces for seamless integration on web and mobile platforms. Features include localization support in over 50 languages, specific regional maps, and geocoding capabilities. Offers enterprise-level features for Premier customers, with support for secure HTTPS access and intranet integration options.”,“categories”:[“geolocation”,“mobile”,“enterprise”,“localization”,“JavaScript”,“integration”]}.

[0048] As another example, a large language model can be called to service rewrite, with the prompt information (i.e., background instructions) input to the large language model being: You are an AI assistant specialized in analyzing and improving service descriptions and categories. Your task is to enhance the clarity of the service description while preserving and possibly 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 description analysis requirements for the large language model are: analyze the existing description and enhance its content, including: clearly explain the main functions of the service; key features and capabilities; target users or use scenarios; any geographical or technical limitations; maintain concise but comprehensive wording; increase technical clarity while preserving the original meaning; include any implied technical requirements. The category handling requirements for the large language model are: completely preserve all existing categories; suggest additional relevant categories based on the following: core functions (e.g., search, integration, visualization), technical components (e.g., APIs, data sources), application domains (e.g., retail, social, finance), user interaction types (e.g., search, browse, analyze). The output set for the large language model is {“title”:“Mashup Name”,“enhanced description”:“Improved description with technical details and clarity.”,“categories”:["additional","relevant","categories"]}. The additional guidelines are: maintain a professional tone to the following standards: use clear technical language; avoid marketing jargon; be accurate and fact-based; enhance the focus of the description to the following standards: technical integration points; core functions; user interaction processes; data sources and APIs; geographical aspects (if relevant); real-time and static data processing; category suggestions should meet the following requirements: related to core functions; reflect technical components; consider user interaction modes; include industry-standard terminology; specific but not overly narrow. Notes: do not delete or modify existing categories; maintain the original title format; focus on technical accuracy and clarity; keep the description concise but complete; ensure that all suggested categories have a basis for description.

[0049] As a specific example, the input to the large language model is {"title": "Mashup: Krillion", "description": "A shopping comparison service focused on local shopping. Search for products nationwide and see inventory at nearby stores.", "categories": ["maps", "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 nationwide product database with a local store inventory system. The service allows users to search for products across 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, encoding the extended semantic text to obtain a semantic query vector.

[0051] In an optional embodiment of the present application, 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 application, the process of text preprocessing of the extended semantic text includes: performing sentence processing on the extended semantic text; removing stop words in the extended semantic text after sentence processing to obtain the final extended semantic text. Specifically, the entire extended semantic text is divided into several short sentences, and stop words in each short sentence are removed to obtain the final extended semantic text. The stop words include, but are not limited to, preset types of structural auxiliary words, conjunctions, virtual words, and mood words.

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

[0055] The extended semantic text in natural language form is encoded by a text encoding model, which maps it to a high-dimensional semantic vector by capturing the semantic features in the extended semantic text, thereby obtaining a semantic query vector. The text encoding model can be any embedding model that can encode text, including but not limited to models based on the Transformer architecture and OpenAI Embedding models obtained by pre-training large language models, etc., without limitation.

[0056] S14, query service descriptions of each service from the service database, and respectively calculate a first similarity score between the semantic query vector and the service description, and a second similarity score between each keyword in the extended semantic text and the service description, obtain a comprehensive score of each service, and screen out a candidate service set having semantic association with the service demand according to the comprehensive score; wherein the service description is used to represent the functional characteristics of the corresponding service.

[0057] The service description of each service is queried from the service database, the service description is used to represent the functional characteristics or application field of the corresponding service, and according to the service description, the relevant service associated with the service demand proposed by the user can be screened out. The similarity between the semantic query vector and each service description is calculated to obtain the first similarity, which is used to measure the association degree between the overall semantics of the service and the extended semantic text. In addition, the second similarity between each keyword in the extended semantic text and each service description is also calculated to measure the relevance of the keyword level and the service content. Through this hybrid intelligent retrieval strategy, the first similarity score and the second similarity score are obtained, and the first similarity score and the second similarity score are fused to calculate the comprehensive score of each service, and a candidate service set having semantic association with the service demand is screened out according to the comprehensive score.

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

[0059] S141, query service descriptions of each service from the service database.

[0060] All services are pre-stored in the service database, wherein each service corresponds to a service description, and the service description can be related to the core function of the service, the adaptation platform, the supported protocol standard, etc., so as to be used for subsequent screening of services adapted to the service demand of the user.

[0061] Steps S142 to S145 are performed for each service:

[0062] S142, encode the service description corresponding to the service to obtain a service description code.

[0063] The service description can be encoded by calling a text encoding model to obtain a service description code. It can be understood that, in order to accelerate the recommendation rate, all service descriptions in the service database can be pre-encoded, and a mapping relationship between the service description code and the corresponding service description and service is established, so that the corresponding service description code can be directly called through the identification information of the service in the subsequent process.

[0064] S143, calculate 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 demand.

[0065] For each service description encoding, the cosine similarity between the semantic query vector and the service description encoding is calculated to obtain the first similarity score between the service and the service demand, i.e. Wherein, sim(q, m) is the first similarity score between the service demand q and the service m, v q is the semantic query vector, v m is the service description encoding of the service m, ‖v q ‖ and ‖v m ‖ respectively represent the vector module length of the semantic query vector v q and the service description encoding v m of the service m. Since the semantic query vector represents the user demand intention obtained via the extended semantic text encoding, and the service description encoding represents the semantic characteristics of the service in the functional and technical layers, by calculating the first similarity score between the two, the matching degree of the service to the user demand in the overall semantic layer can be reflected.

[0066] S144, 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 between the service and the service demand.

[0067] In order to more comprehensively evaluate the relevance between the service description and the service demand, the similarity score between each keyword and each service description is also calculated by the BM25 algorithm, and the second similarity score is obtained by accumulating the similarity scores of all keywords in the extended semantic text and the service description of the same service. This score reflects the matching degree between the service content and the demand text at the keyword level, which can be used together with the first similarity score for subsequent service screening and sorting to make the screening result more accurate.

[0068] In an optional embodiment of the present application, step S144 includes the following processing process: for each keyword in the extended semantic text: calculating the relevance score between the keyword and the service description corresponding to the service Wherein, ws(w, m) is the relevance score between the keyword w and the service description of the service m, f(w, m) is the frequency of the keyword w in the service description of the service m, k1 and b are preset parameters, |m| is the length of the service description, and agdl is the average length of all service descriptions; the relevance scores between all keywords in the extended semantic text and the service description corresponding to the service are summarized to obtain the second similarity score between the service and the service demand.

[0069] Specifically, for each keyword w in the extended semantic text, the following process is performed: the correlation score between the keyword w and the service description of the current service m is calculated. By summing the correlation scores of all keywords in the extended semantic text, the second similarity score score(q, m) = ∑ w∈q ws(w, m) between the service m and the service requirement q is obtained. The second similarity score makes up for the keyword information that the overall semantic matching may miss, 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 a comprehensive score of the service.

[0071] For each service m: the first similarity score and the second similarity score are weighted and summed according to a preset weighting factor to obtain a comprehensive score of the service m final_sore(q, m) = a • sim(q, m) + β • score(q, m). Wherein, a and β are preset weighting factors (such as both are preset to 0.5), final_sore(q, m) is the comprehensive score of the service m relative to the service requirement q. The comprehensive score combines deep semantic analysis and global keyword matching, which can capture both functional relevance between APIs and comprehensive coverage of technical terms to improve the accuracy of subsequent recommendations.

[0072] S146, all services are sorted according to the corresponding comprehensive scores, and services with a comprehensive score greater than a preset score threshold or a comprehensive score in the top N are selected as a candidate service set; wherein N is a positive integer.

[0073] The comprehensive scores of all services are arranged in descending order, and services with a comprehensive score higher than a preset score threshold or directly selected services with a comprehensive score in the top N are selected as a candidate service set. These selected services have a high relevance to the service requirement given by the user, and the APIs filtered out subsequently will have high accuracy.

[0074] S15, determine all application programming interfaces corresponding to the candidate service set, according to the usage frequency of various application programming interfaces, the semantic similarity between the preset labels of the various application programming interfaces and the semantic query vector, and call the large language model to filter out a final application programming interface set and recommend; wherein each service corresponds to at least one application programming interface, and each application programming interface is preset with at least one label representing its technical characteristics.

[0075] All corresponding APIs are extracted from the candidate service set to form a candidate application programming interface set. The frequency of each API's usage across all service calls is counted to determine its versatility. The semantic similarity between each API's preset label and the semantic query vector is calculated to determine the API's compatibility with the current service requirements. By comprehensively evaluating these two aspects, a large language model is used to ultimately select and recommend 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. Aggregate 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] Aggregate all APIs corresponding to each service in the candidate service set to obtain the candidate application programming interface 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, that is, the same API may appear multiple times in the candidate service set.

[0079] S152. Count 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 a first target interface sequence; where L is a positive integer.

[0080] For the candidate application programming interface set S = {s1,s2,…,s N Each API in} is s i : Count the number of times it appears in the entire candidate application programming interface set and use it as the usage frequency. Arrange all APIs in descending order of usage frequency, and select the top L APIs with the highest usage frequency, and arrange them in descending order according to the corresponding usage frequency 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 label, and calculate the semantic similarity between the label and the semantic query vector.

[0082] For each API in the candidate application programming interface set, obtain its corresponding preset label and encode the label into a label vector. Calculate the semantic similarity between the label and the semantic query vector wherein g(q, m) is the semantic similarity between the label of service m and the service requirement q, t s is the encoded label vector of label s, v q is the semantic query vector.

[0083] S154, according to the semantic similarity, all application programming interfaces are sorted, and the first T application programming interfaces are selected to form a second target interface sequence; wherein T is a positive integer.

[0084] All APIs in the candidate application programming interface set are arranged in descending order according to the semantic similarity between their corresponding labels and the semantic query vector, and the first T APIs are arranged in descending order according to the corresponding semantic similarity to form a second target interface sequence S g .

[0085] In an optional embodiment of the present application, step S154 includes the following processing process: according to the semantic similarity, all application programming interfaces are sorted to form a candidate interface sequence; from the candidate interface sequence, the application programming interfaces are sequentially selected, and for each selected application programming interface, the following process is performed: determine whether the application programming interface is not in the first target interface sequence; if yes, the application programming interface is added to the second target interface sequence, and a new application programming interface is selected, until the number of application programming interfaces in the second target interface sequence reaches T or all application programming interfaces are selected; wherein the initial state of the second target interface sequence is an empty set; otherwise, a new application programming interface is selected until all application programming interfaces are selected.

[0086] In the present application, in order to improve the accuracy and coverage of API recommendation, a hybrid retrieval mechanism combining semantic understanding ability and traditional information retrieval method is proposed. Through a two-stage optimization sorting mechanism, high-frequency co-occurring reliable API combinations are preferentially screened according to API usage frequency, and candidate results are fine-grained calibrated combined with context semantic similarity, so as to identify API combinations that truly have dependency relationship, so as to exclude 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 the candidate interface sequence, an API is selected in turn, and the following process is performed for the selected API: determine whether the API is not in the first target interface sequence obtained previously: if the API is not in the first target interface sequence, directly add the API to the second target interface sequence, and continue to process the next API until one of the following conditions is met to obtain a complete second target interface sequence: condition one: the number of API categories in the second target interface sequence reaches a preset threshold T; condition two: all APIs in the candidate interface sequence are traversed according to the above process. Conversely, if the current API is in the first target interface sequence, skip the API and continue to select the next one for processing until all APIs are selected. It can be understood that the initial state of the second target interface sequence is an empty set. Through the above process, APIs that have a certain degree of association with the user's service demand although have a low usage frequency can be supplemented to improve the completeness of the recommendation.

[0088] S155, aggregate the first target interface sequence and the second target interface sequence, obtain a final application programming interface sequence using a large language model, and recommend the final application programming interface sequence.

[0089] Specifically, all APIs in the first target interface sequence and the second target interface sequence are arranged in sequence to obtain a final application programming interface sequence. The final APIs comprehensively consider the stability of the interface and the semantic matching degree, thereby ensuring that the recommended APIs have both technical practicability and meet the functional and compatibility requirements of the current service demand.

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

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

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

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

[0094] In this application, based on the chain of thought prompt strategy, the decision-making and recommendation tasks are transformed into a structured reasoning problem to generate the final recommended API. During this period, the large language model acts as a domain expert developer. The prompt input to the large language model provides the basic context for API ecosystem and service recommendations, and guides the large language model through a systematic reasoning process to gradually analyze the service requirements and technical constraints proposed by the user, thereby ensuring that the final recommendation results have high accuracy in terms of functional adaptability and technical compatibility. Specifically, for each candidate target API in the candidate target interface sequence: the Chain of Thought (CoT) reasoning strategy is adopted to input the semantic query vector, all labels of the candidate target API and the service description of the corresponding service into the large language model, and gradually analyze whether the candidate target API meets the core functions, technical protocols, deployment platforms and other requirements in the service requirements. In addition, the interface compatibility and combination feasibility between it and other services are also evaluated to determine whether the candidate target API is the final recommended interface.

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

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

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

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

[0099] For each candidate target API: determine whether its adaptation conclusion meets the adaptation conditions. If so, the candidate target API is selected as the final recommended interface. Otherwise, the candidate target API is excluded and the next candidate target API is selected for judgment.

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

[0101] First, the adaptation conclusion is analyzed to obtain a function matching conclusion and a technical compatibility conclusion in the adaptation conclusion.

[0102] The adaptation conclusion is structurally analyzed to extract the function matching conclusion and the technical compatibility conclusion from the analyzed content. The function matching conclusion is used to represent whether the function supported by the API conforms to the core function in the service requirement proposed by the user. The technical compatibility conclusion is used to represent the adaptation degree of the API in the technical aspect with the expected technical environment.

[0103] Then, it is judged whether the function matching conclusion conforms to the function matching condition set by the service requirement and whether the technical compatibility conclusion conforms to the interface compatibility requirement. If both conform, the adaptation conclusion conforms to the adaptation condition set based on the service requirement. Otherwise, the adaptation conclusion does not conform to the adaptation condition set based on the service requirement.

[0104] It is judged whether the function matching conclusion conforms to the function matching condition set according to the service requirement, for example, whether the target function module is covered or the specified operation behavior is supported. In addition, it is also judged whether the technical compatibility conclusion meets the interface compatibility requirement, for example, the support situation of a specific platform or a communication protocol. If both of the two judgments conform, it is determined that the adaptation conclusion conforms to the adaptation condition. Otherwise, it is determined that the adaptation conclusion does not conform to the adaptation condition.

[0105] S1553, all final recommended interfaces are summarized to form a final application programming interface sequence and are recommended.

[0106] In an optional embodiment of the present application, the process of screening the final application programming interface set and recommending includes the following process: the final application programming interface set is generated into a structured JSON object and is recommended. The JSON object includes the service requirement and the final recommended various application programming interfaces.

[0107] In a specific example, based on the thought chain reasoning strategy, the specific reasoning manner of calling a large language model to determine whether the candidate target application programming interface is the final recommended interface is as follows: first, analyze the functional requirements, the large language model carefully reads the service requirements of the user, and extracts the key functional requirements. Secondly, filter the API: view the description and label of each API in all candidate target application programming interfaces, judge whether it meets the extracted functional requirements, and only keep the API that meets the requirements. Then, for each API that remains, extract its title field, and include these title fields in the final output result. Further, to ensure the completeness of the recommended result, it is also necessary to verify whether the selected API fully covers all functional requirements of the service requirements. For example, if a single API cannot meet all functional requirements, multiple APIs can be combined to achieve functional complement. The final application programming interface sequence output by the large language model must exactly contain k entries as the recommended result.

[0108] The data of the present application adopts the ProgrammableWeb dataset for experiments, which is 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. In order to discuss the performance level of the method, ten methods are selected for comparison, which are NGCF (graph collaborative filtering method), T2L2 (Transformer-to-Label model for service text representation), TextCNN (convolutional neural network structure applied to text classification task), ServeNet (deep learning based service recommendation network), MTFM (multi-task fusion model), MGSR (multi-granularity service recommendation method), SEHGN (structure enhanced hypergraph neural network), LLM Enhanced GNN (method combining large language model and graph neural network), Native RAG (standard retrieval augmented generation method), Retrieval Only (only using retrieval), ServiceRAG (ours) (the present application). Table 1 and Table 2 show the evaluation results of all methods on the dataset. Among them, Recall@k represents the recall rate of the top k results in the recommendation list, Precious@k represents the accuracy rate of the top k results in the recommendation list, FI@k represents the F1 score of the top k results in the recommendation list, and NDCG@k represents the normalized discounted cumulative gain of the top k results in the recommendation list.

[0109] Table 1 Recall and accuracy of each method in the top k results of the recommendation list

[0110]

[0111] Table 2. F1 scores and normalized discounted cumulative gain of each method on the top-k results of the recommendation list

[0112]

[0113] The limitations of traditional methods in service recommendation are clearly demonstrated in Tables 1 and 2. Traditional deep learning methods such as T2L2 (42.70% Recall@5), TextCNN (41.61% Recall@5), and ServeNet (43.35% Recall@5) perform relatively weakly, with a significant gap compared to ServiceRAG (59.77% Recall@5). This significant performance gap empirically validates the argument that traditional methods are insufficient in addressing the complex needs of service selection and service development. The lower performance of these methods is attributed to their inability to capture the complex technical constraints and compatibility requirements that are crucial for service integration. The experimental results also provide strong evidence of the limitations of graph neural network (GNN) based methods. As highlighted in this application, GNN methods face challenges such as potentially misleading co-occurrence patterns and difficulty in identifying true service dependency relationships. This is reflected in the performance of NGCF (25.19% Recall@5) and MGSR (41.88% Recall@5), which significantly lag behind ServiceRAG. The relatively poor performance of NGCF demonstrates the limitations of pure graph-based methods in capturing true service relationships. SEHGN attempts to incorporate semantic information, although it shows improvement, it is still insufficient (38.26% Recall@5), indicating that simply adding semantic features to graph-based models is not sufficient to address the complex needs of service recommendation.

[0114] The results validate the hypothesis of combining large language models (LLMs) with retrieval-augmented generation (RAG) for service recommendation. The performance advantage of ServiceRAG is consistent across different k values, with significant improvements in both precision and recall metrics. The higher precision value at k = 5 (19.77% compared to 13.98% for T2L2) is particularly indicative of ServiceRAG's ability to make more accurate recommendations at key top positions, which is crucial for real-world service development scenarios. ServiceRAG significantly outperforms Native RAG (58.28% Recall@5) and the retrieval-only method (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 contextually relevant service recommendations by combining semantic understanding and structured retrieval of technical documentation.

[0115] In the answer generation stage, the application compares the effect difference between using the thought chain reasoning and the traditional generation method, as shown in Figure 2 The results show that the thought chain-based prompting method is significantly better than the conventional method in terms of recall, precision (P), F1 score (F1), and normalized discounted cumulative gain (NDCG). This shows that through task modeling, large language models can understand the functional requirements and technical constraints of the system reasoning service from the perspective of domain experts under clear instructions, thereby generating more accurate service decision recommendations.

[0116] To evaluate the impact of API ranking strategies on recommendation performance, the application compares the proposed scheme and three other different API ranking schemes under the ServiceRAG framework. The results are shown in Table 3. From the table, it can be seen that the API ranking based on usage frequency significantly improves the recommendation performance, with the recall rate increasing from 61.16% to 68.11%, verifying the gain effect of API usage frequency on recommendation accuracy. It is worth noting that the re-ranking based on semantic similarity alone is slightly lower than the baseline (recall rate decreases from 61.16% to 58.82%). However, when frequency and semantic similarity are combined, the recommendation performance is further optimized (recall rate increases to 68.21%). This shows that although the semantic similarity alone has limited effect, when combined with high usage frequency, those APIs that are highly consistent with the target Mashup category in terms of functional tags can still effectively meet the demand.

[0117] Table 3 Ablation experiment results on ranking methods

[0118]

[0119] As Figure 3As shown, the service recommendation decision system 300 generated based on large model retrieval enhancement includes a service demand acquisition module 310, a semantic analysis module 320, an encoding module 330, a service matching module 340, and an interface screening module 350. The service demand acquisition module 310 is configured to acquire unstructured service demand. The semantic analysis module 320 is configured to call a large language model to perform semantic analysis and expansion on the service demand, and generate unstructured expanded semantic text. The encoding module 330 is configured to encode the expanded semantic text to obtain a semantic query vector. The service matching module 340 is configured to query pre-stored service descriptions of various services from a service database, and respectively calculate 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 of each service, and screen out a candidate service set having semantic association with the service demand according to the comprehensive score; wherein the service description is configured to represent the functional characteristics of the corresponding service. The interface screening module 350 is configured to determine all application programming interfaces corresponding to the candidate service set, and according to the usage frequency of various application programming interfaces, the semantic similarity between the preset labels of the various application programming interfaces and the semantic query vector, call the large language model to screen out a final application programming interface set and make a recommendation; wherein each service corresponds to at least one application programming interface, and each application programming interface is pre-provided with at least one label representing the technical characteristics thereof.

[0120] The specific limitations of the service recommendation decision system generated based on large model retrieval enhancement can be referred to the limitations of the service recommendation decision method generated based on large model retrieval enhancement in the foregoing, which will not be repeated here. Each module in the service recommendation decision system generated based on large model retrieval enhancement can be realized by software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor in the computer device in hardware format, or stored in the memory in the computer device in software format, so that the processor can call the operations of each module.

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

[0122] As shown in Figure 4 The electronic device 4 can include a memory 41, a processor 42, and a bus, and can further include a computer program stored in the memory 41 and executable on the processor 42, such as a service recommendation decision program generated based on large model retrieval enhancement.

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

[0124] The processor 42 can be composed of an integrated circuit in some embodiments, such as a single packaged integrated circuit or a plurality of packaged integrated circuits with the same or different functions, including one or more combinations of a central processing unit (CPU), a microprocessor, a digital processing chip, a graphics processor, and various control chips, etc. The processor 42 is the control core of the electronic device 4, which connects various components of the entire electronic device 4 through various interfaces and lines, and executes various functions and processes data of the electronic device 4 by running or executing programs or modules stored in the memory 41 (such as a recommendation program of an application programming interface, etc.) and calling data stored in the memory 41.

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

[0126] For example, the computer program can be divided into one or more modules, which are stored in the memory 41 and executed by the processor 42 to complete the present application. One or more modules can be a series of computer program instructions capable of completing a specific function, which are used to describe the execution process of the computer program in the electronic device 4. For example, the computer program can be divided into a service demand obtaining module 310, a semantic analysis module 320, an encoding module 330, a service matching module 340, and an interface screening module 350.

[0127] The integrated units in the form of software function modules can be stored in a computer readable storage medium, which can be nonvolatile or volatile. The software function modules are stored in a storage medium, and include a plurality of instructions for enabling a computer device (which can be a personal computer, a computer device, or a network device, etc.) or a processor to execute part of the service recommendation decision method based on large model retrieval enhancement generation of various embodiments of the present application.

[0128] The above embodiments only exemplarily illustrate the principles and effects of the present application, and are not intended to limit the present application. Any person skilled in the art can modify or change the above embodiments without departing from the spirit and scope of the present application. Therefore, all equivalent modifications or changes made by those skilled in the art without departing from the spirit and technical idea disclosed by the present application should be covered by the claims of the present application.

Claims

1. A service recommendation decision method based on large model retrieval enhancement generation, characterized by: The method comprises: Capture unstructured service needs; Calling a large language model to perform semantic analysis and expansion on the service requirements, generating unstructured extended semantic text; Encoding the extended semantic text to obtain a semantic query vector; Querying a service database for pre-stored service descriptions of each service, 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 extended semantic text and the service description, respectively, to obtain a comprehensive score for each service, and based on this score, screening a set of candidate services that have a semantic association with the service requirement; wherein the service description is used to characterize the functional characteristics of the corresponding service; Determine all application programming interfaces corresponding to the candidate service set, and based on the usage frequency of various application programming interfaces and the semantic similarity between their preset labels and the semantic query vector, call the large language model to screen out a final set of application programming interfaces and make recommendations; wherein each service corresponds to at least one application programming interface, and each application programming interface is preset with at least one label that characterizes its technical characteristics.

2. The service recommendation decision method based on large model retrieval enhancement generation according to claim 1 is characterized in that: The calling of the large language model to perform semantic analysis and expansion on the service requirement to generate unstructured extended semantic text includes: Calling the large language model to perform semantic analysis on the service demand and generate semantic text; The large language model is called again to perform semantic completion processing on the semantic text to generate an extended semantic text with a unified expression style.

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

4. The service recommendation decision method based on large model retrieval enhancement generation according to claim 3 is characterized in that: The preprocessing of the extended semantic text to obtain the final extended semantic text includes: Performing sentence processing on the extended semantic text; The stop words in the expanded semantic text after sentence segmentation are removed to obtain the final expanded semantic text.

5. The service recommendation decision method based on large model retrieval enhancement generation according to claim 1 is characterized in that: The service description code of each service is queried from the service database, and a first similarity score between the semantic query vector and the service description code is calculated, as well as a 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 based on the score, a set of candidate services having a semantic association with the service requirement is screened out, including: Query the service description of each service from the service database; For each service: Encode the service description corresponding to the service to obtain a service description code; Calculate 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; Calculate, based on the BM25 algorithm, a correlation score between each keyword in the extended semantic text and the service description corresponding to the service to obtain a second similarity score between the service and the service requirement; Perform a weighted summation of the first similarity score and the second similarity score to obtain a comprehensive score for the service; All services are sorted according to their corresponding comprehensive scores, and services with comprehensive scores greater than a preset score threshold or whose comprehensive scores are in the top N are selected as a candidate service set; where N is a positive integer.

6. The service recommendation decision method based on large model retrieval enhancement generation according to claim 5 is characterized in that: 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: calculate the relevance score between the keyword and the service description corresponding to the service Where ws(w,m) is the correlation score between keyword w and the service description of service m, f(w,m) is the frequency of keyword w in the service description of service m, k1 and b are preset parameters, |m| is the length of the service description, and agdl is the average length of all service descriptions; The relevance scores between all keywords in the extended semantic text and the service description corresponding to the service are summarized to obtain a second similarity score between the service and the service requirement.

7. The service recommendation decision method based on large model retrieval enhancement generation according to claim 1 is characterized in that: The determining of all corresponding application programming interfaces in the candidate service set, based on the usage frequency of various application programming interfaces and the semantic similarity between their corresponding labels and the semantic query vector, and calling the large language model to screen out a final set of application programming interfaces and make recommendations, includes: Summarizing 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; Counting the usage frequency of each application programming interface in the candidate application programming interface set, arranging the various application programming interfaces in order based on the usage frequency, and selecting the top L application programming interfaces with the highest usage frequency to form a first target interface sequence; where L is a positive integer; For each application programming interface in the candidate application programming interface set: determining its corresponding label, and calculating the semantic similarity between the label and the semantic query vector; Sort all application programming interfaces according to semantic similarity, and select the top T application programming interfaces to form a 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 a final application programming interface sequence and make a recommendation.

8. The service recommendation decision method based on large model retrieval enhancement generation according to claim 7 is characterized in that: The step of sorting all application programming interfaces according to semantic similarity and selecting the top T application programming interfaces as the second target interface sequence includes: Sort all application programming interfaces according to semantic similarity to form a candidate interface sequence; Selecting application programming interfaces in sequence 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 counted into the second target interface sequence, and new application programming interfaces are continuously selected until the number of application programming interfaces in the second target interface sequence reaches T or all application programming interfaces are selected; wherein the initial state of the second target interface sequence is an empty set; Otherwise, continue selecting new APIs until all APIs are selected.

9. The service recommendation decision method based on large model retrieval enhancement generation according to claim 7 is characterized in that: The step of aggregating the first target interface sequence and the second target interface sequence to obtain a final application programming interface sequence and recommending the final application programming interface sequence includes: Aggregating 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, analyzing the candidate target application programming interface based on the semantic query vector, all tags and service descriptions of the candidate target application programming interface, and determining whether the candidate target application programming interface is the final recommended interface; Summarize all the final recommended interfaces to form the final application programming interface sequence and make recommendations.

10. The service recommendation decision method based on large model retrieval enhancement generation according to claim 9 is characterized in that: The method of calling the large language model based on the thought chain reasoning strategy, analyzing the candidate target application programming interface based on the semantic query vector, the label of the candidate target application programming interface, and the service description, and determining whether the candidate target application programming interface is the final recommended interface includes: Inputting the semantic query vector, all labels and service descriptions of the candidate target application programming interface into the large language model, performing structured reasoning, and obtaining an 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 requirements, the candidate target application programming interface will be used as the final recommended interface; If not, the candidate target application programming interface is not the final recommended interface.

11. The service recommendation decision method based on large model retrieval enhancement generation according to claim 10 is characterized in that: The determining whether the adaptation conclusion meets the adaptation condition set based on the service requirement includes: Analyze the adaptation conclusion to obtain the functional matching conclusion and technical compatibility conclusion in the adaptation conclusion; Determine whether the functional matching conclusion meets the functional matching conditions set by the service requirements, and whether the technical compatibility conclusion meets the interface compatibility requirements; If all of them 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.

12. The service recommendation decision method based on large model retrieval enhancement generation according to claim 1 is characterized in that: The screening out of the final set of application programming interfaces and making recommendations includes: generating a structured JSON object from the final set of application programming interfaces and making recommendations; wherein the JSON object includes the service requirements and various finally recommended application programming interfaces.

13. A service recommendation decision system based on large model retrieval enhancement generation, characterized in that: The system comprises: Service demand acquisition module, used to obtain unstructured service requirements; A semantic parsing module, configured to call a large language model to perform semantic parsing and expansion on the service requirements, and generate unstructured extended semantic text; an encoding module, configured to encode the extended semantic text to obtain a semantic query vector; A service matching module is configured to query a service database for pre-stored service descriptions of each service, and calculate a first similarity score between the semantic query vector and the service description, as well as a second similarity score between each keyword in the extended semantic text and the service description, to obtain a comprehensive score for each service, and based on this score, screen a set of candidate services that have a semantic association with the service requirement; wherein the service description is used to characterize the functional characteristics of the corresponding service; The interface screening module is used to determine all application programming interfaces corresponding to the candidate service set, and based on the usage frequency of various application programming interfaces and the semantic similarity between their preset labels and the semantic query vector, call the large language model to screen out the final set of application programming interfaces and make recommendations; wherein each service corresponds to at least one application programming interface, and each application programming interface is preset with at least one label representing its technical characteristics.

14. An electronic device, characterized in that: The electronic device comprises: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the service recommendation decision method based on large model retrieval enhanced generation as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor of a computer, the computer is caused to execute the service recommendation decision method based on large model retrieval enhancement generation as described in any one of claims 1 to 12.

Images