A knowledge-guided large language model-based trusted API recommendation method

Abstract

The application discloses a knowledge-guided trusted API recommendation method based on a large language model, and the core idea of the method is to improve the trustworthiness of the LLM in the API recommendation task by using API knowledge. Specifically, in view of the untrustworthiness of the LLM in API recommendation, the application proposes knowledge-guided data enhancement to improve the ability of the LLM to establish the correlation between the user-specified type and the API sequence; proposes knowledge-guided beam search to guide the LLM to generate an API that actually exists and whose calling conditions can be met; and proposes knowledge-guided reordering to optimize the API sequence recommendation list, so that the API sequence that matches the interface parameter type is ranked more in front in the recommendation result. The application has the advantages that API recommendation can be realized under the constraint of the interface parameter type, and the trustworthiness of the large model in the API recommendation task can be improved through high-quality prior knowledge in the API knowledge graph.

Description

Technical Field

[0001] This invention relates to an application programming interface (API) recommendation method, specifically a knowledge-guided framework for LLM-based trustworthy API recommendation (KG4LLM). Background Technology

[0002] As my country's social informatization deepens, improving software development and update efficiency has become a hot research topic in software engineering. To accelerate software development and avoid reinventing the wheel, developers often use APIs provided by libraries or frameworks. Specifically, developers typically call a set of APIs in a specific order to implement a particular function; this set of APIs called in a specific order is called an API sequence. In recent years, the number of APIs has exploded, making it difficult even for experienced developers to master their usage. Therefore, researching API recommendation methods—that is, recommending API sequences that meet a developer's specific functional requirements—can compensate for developers' lack of API knowledge.

[0003] In team-based software development, different units or modules often require simultaneous development by different developers to improve efficiency. To ensure smooth integration after each unit or module is completed, the parameter formats of their interfaces often need to be agreed upon in advance. Therefore, developers often need to implement specific functionalities within the constraints of predefined interface parameter types. In API recommendation tasks for this scenario, the recommended API sequence must not only meet the developer's functional requirements but also match the predefined interface parameter types. This invention refers to this type of API recommendation task as API recommendation under specific interface parameter types (APIRIP). Figure 1 An instance of APIRIP is shown.

[0004] In recent years, Large Language Models (LLMs) have demonstrated remarkable capabilities in code generation and recommendation tasks. Therefore, implementing API recommendation tasks based on LLMs is a viable approach. However, the "illusion" of LLMs leads to unreliability issues in API recommendation tasks. For example... Figure 2As shown, the untrust issues of LLM in API recommendation tasks can be divided into three categories: recommending fictitious APIs, recommending APIs whose calling conditions cannot be met, and the external parameter types on which the recommended API sequence depends are inconsistent with the predefined interface parameter types.

[0005] Currently, no research has been found on API recommendation under interface parameter type constraints, nor has any literature been found on using API knowledge to improve the credibility of LLM in API recommendation tasks. Summary of the Invention

[0006] This invention addresses API recommendation scenarios constrained by interface parameter types by providing a knowledge-guided, large language model-based, trustworthy API recommendation method. The core idea is to leverage API knowledge to enhance the trustworthiness of an LLM (Large Language Model) in API recommendation tasks. Specifically, addressing the untrustworthiness issues of LLMs in API recommendation (i.e., recommending fictitious APIs, recommending APIs with unmet calling conditions, or recommending API sequences that do not match interface parameter types), this invention proposes knowledge-guided data augmentation to improve the LLM's ability to establish correlations between interface parameter types and API sequences; it proposes knowledge-guided bundle search to guide the LLM to generate real APIs with satisfyable calling conditions; and it proposes knowledge-guided reordering to optimize the API sequence recommendation list, giving higher rankings to API sequences matching interface parameter types. The advantages of this invention are its ability to achieve API recommendation under interface parameter type constraints and its ability to improve the trustworthiness of large models in API recommendation tasks through high-quality prior knowledge from API knowledge graphs.

[0007] The objective of this invention is achieved through the following technical solution:

[0008] A knowledge-guided, large language model-based trusted API recommendation method includes the following steps:

[0009] Step 1: Build an API knowledge base for APIRIP tasks;

[0010] Step 2: Construct a training dataset for the APIRIP task;

[0011] Step 3: Use knowledge-guided data enhancement to fine-tune the large language model;

[0012] Step 4: Generate an API sequence recommendation list using knowledge-guided bundle search;

[0013] Step 5: Optimize the API sequence recommendation list using knowledge-guided reordering.

[0014] Compared with the prior art, the present invention has the following advantages:

[0015] 1. The method provided by this invention enables the recommended API sequence to meet the functional requirements of developers while conforming to specific interface parameter types.

[0016] 2. The KG4LLM framework proposed in this invention can improve the credibility of LLM in API recommendation tasks.

[0017] 3. This invention can be applied to LLMs of various architectures and sizes, and has good versatility. Attached Figure Description

[0018] Figure 1 It is an instance of an APIRIP task.

[0019] Figure 2 This is an example of the untrust problem in LLM for API recommendation tasks.

[0020] Figure 3 This is the overall flowchart of the API recommendation framework KG4LLM proposed in this invention.

[0021] Figure 4 This is an API ontology structure diagram for API recommendation tasks.

[0022] Figure 5 This is an example diagram of API knowledge extraction.

[0023] Figure 6 This is an instance diagram of the API recommendation dataset construction.

[0024] Figure 7 This is an example diagram of knowledge-guided data augmentation.

[0025] Figure 8 This is a diagram illustrating knowledge-guided bundle search and reordering examples. Detailed Implementation

[0026] The technical solution of the present invention will be further described below with reference to the accompanying drawings, but it is not limited thereto. Any modifications or equivalent substitutions to the technical solution of the present invention that do not depart from the spirit and scope of the technical solution of the present invention should be covered within the protection scope of the present invention.

[0027] This invention addresses API recommendation scenarios constrained by interface parameter types by providing a knowledge-guided, large language model-based reliable API recommendation method. First, in the data mining phase, an API knowledge graph is constructed by mining JDK API online documentation, and an APIRIP dataset is built by mining Java open-source projects. Second, in the large model fine-tuning phase, the dataset is expanded using knowledge-guided data augmentation, and the large model is fine-tuned using the augmented dataset, thereby enhancing its API recommendation capabilities. Finally, in the API recommendation phase, an API sequence recommendation list is generated based on the fine-tuned large model using knowledge-guided beam search, and this list is optimized using knowledge-guided reordering. Figure 3 As shown, the method specifically includes the following steps:

[0028] Step 1: Build an API knowledge base for APIRIP tasks.

[0029] Building an API knowledge base for APIRIP tasks is fundamental for subsequent knowledge-guided data augmentation, knowledge-guided bundle search, and knowledge-guided reordering. The specific steps are as follows:

[0030] Step 11: Design the API ontology model. For example... Figure 4 As shown, the concepts in the API ontology model include: basic data type, class, interface, enum, record, API or method, package, and member. Relationships include: extend, implement, contain, and type. <dim>(dim represents the dimension of the variable type), return relation "return <dim>(dim represents the dimension of the return value), parameter<idx,dim> (idx represents the parameter index, dim represents the parameter dimension). Attributes include: API, method, or member modifier "field". Values ​​include: public, private, protected, and static.

[0031] Step 12: Using the requests tool, starting from the main page of the official Java JDK online documentation (https: / / docs.oracle.com / en / java / javase / 20 / docs / api / index.html), recursively retrieve all API documentation pages and save them as ".html" files.

[0032] Step 13: Use the BeautifulSoup tool to parse each ".html" file, and extract the API entity, relation, attribute and value from the corresponding fields according to the API ontology designed in Step 11, to obtain a set of triples consisting of "entity-relationship-entity" or "entity-attribute-value".

[0033] Step 14: Import all "entity-relationship-entity" and "entity-attribute-value" triples into the Neo4j graph database to obtain a graph-formatted API knowledge graph.

[0034] Step 2: Construct a training dataset for the APIRIP task.

[0035] Construct a training dataset for the APIRIP task to provide training data for the subsequent LLM fine-tuning process. The specific steps are as follows:

[0036] Step 21: Search and download all Java projects from 2008 to the present that contain at least one star on GitHub, and perform steps 22 to 24 for each Java project that meets the criteria.

[0037] Step 22: Find all methods in the Java project that meet the following conditions: (1) have function annotations; (2) only call JDK API methods.

[0038] Step 23: For the i-th method that satisfies the conditions described in Step 22, add the method's functional annotation (doc). i As a functional description, the method's parameter list is used as the interface parameter type list param. i And according to the API sequence parsing rules defined in DeepAPI, the API sequence apiseq is parsed out. i .

[0039] Step 24: Combine the triples [doc] i ,param i apiseq i This is added to the APIRIP dataset as a training data point.

[0040] Step 3: Use knowledge-guided data enhancement to fine-tune the large language model.

[0041] Knowledge-guided data augmentation generates training data containing more "interface parameter type-API sequence" combinations to enhance the LLM's ability to establish a mapping relationship between interface parameter types and API sequences, thereby alleviating the problem of mismatch between the API sequences recommended by the LLM and the interface parameter types. Subsequently, the LLM is fine-tuned using the augmented dataset. The specific steps are as follows:

[0042] Step 31: Perform steps 32 to 318 on each data point in the original APIRIP dataset to obtain the corresponding augmented data. Mix the obtained augmented data with the original dataset to obtain the augmented dataset. After performing data augmentation operations on each data point, proceed to step 319.

[0043] Step 32: Initialization phase of data augmentation: Initialize the API index i of the current traversal to 0; cache the currently available variable types. t This is a collection consisting of entities of type "base type", the variable types of all static public members, all entities contained in the "java.lang" package, and all entities that support encapsulation mechanisms; the currently searched API sequence apiseq cur An empty list; the currently searched parameter param cur An empty list; the currently found list of comments, specified variable types, and API sequence triples, answers, is an empty list.

[0044] Step 33: Input the raw data for data augmentation, which is a triple containing the function description doc, API sequence apiseq, and interface parameter type param; denote the current API index as i; denote the currently available variable type cache as buff. t Let the enhanced API sequence be apiseq. cur Let the enhanced interface parameter type be param. cur Let answers be the enhanced annotations, the specified variable types, and the list of API sequence triples; let G be the API knowledge base.

[0045] Step 34: Determine if the size of `answers` exceeds the specified threshold N. If it does, return `answers`; otherwise, proceed to step 35. In this invention, the threshold N controls the execution time of the data augmentation algorithm, preventing it from running too long. The threshold N can be set to around 1000.

[0046] Step 35: Determine if i is equal to the length of apiseq. If yes, proceed to step 36; otherwise, proceed to step 39.

[0047] Step 36: Determine the value of param cur If it is exactly the same as param, it means that duplicate data has been generated. Discard it and return answers directly. Otherwise, proceed to step 37.

[0048] Step 37: Calculate apiseq using the following formula. cur score cur :

[0049]

[0050] Where len(·) refers to the length of the API sequence; return G (·) refers to retrieving the return value type of a given API from the API knowledge base G; requires G (·) refers to retrieving a set of requirement variable types for a given single API or sequence of APIs from the API knowledge base G. The requirement variable types of an API include all variable types in the API's parameter table. Additionally, if the API is not a static method, the API's requirement variable types also include the class, interface, enumeration, or record to which the API belongs.

[0051] Step 38: Combine the triple [score] cur ,param cur apiseq cur Add it to answers and return answers.

[0052] Step 39: Iterate through each overloaded form of API in the API knowledge base apiseq[i] and execute steps 310 to 317.

[0053] Step 310: Let require cur Equals requires G (API).

[0054] Step 311: Protect the scene, and save the param cur apiseq cur buff t And back up i to the cache.

[0055] Step 312: [The text appears to be incomplete and requires further context.] cur It exists in but not in buffs t Add the variable type to param cur middle.

[0056] Step 313: Add the API's return value, along with any classes, interfaces, enumerations, or records that it directly or indirectly inherits from or implements, to the buff. t middle.

[0057] Step 314: Add the API to apiseq cur middle.

[0058] Step 315: Let i = i + 1, and obtain answers by recursively executing step 33.

[0059] Step 316: Restore the scene, and set param cur apiseq cur buff t And i is restored to a backup in the cache.

[0060] Step 317: If all overloaded forms of the API have been traversed, return answers; otherwise, return to step 39 to continue traversing other overloaded forms of the API.

[0061] Step 318: Sort all [score, param, apiseq] triples in answers in ascending order of score, and output the top K [param, apiseq] pairs. Combine each pair with the corresponding doc to form K new data entries. In this invention, K is mainly used to control the number of new augmented data entries output by the data augmentation algorithm. To avoid generating too much augmented data, K can be set to 5.

[0062] Step 319: Fine-tune the LLM using the augmented dataset: For training data in the form [doc, apiseq, param], encode doc and param with "..." <sep>"After being concatenated as a separator, it is used as the model input, and apiseq is used as the expected output. The LLM is then fine-tuned directly using the fine-tuning method provided by the LLM itself."

[0063] Step 4: Generate a list of recommended API sequences using knowledge-guided bundle search.

[0064] Knowledge-guided bundle search is used to guide the LLM to generate real-world APIs whose calling conditions can be met during the bundle search process. The specific steps are as follows:

[0065] Step 41: Obtain the list of interface parameter types param by parsing the interface definition in the user's development environment.

[0066] Step 42: Enter a text description (doc) of the user's desired functionality.

[0067] Step 43: Separate doc and param into " <sep>The input is constructed by concatenating characters as separators.

[0068] Step 44: Initialization phase of beam search: Initialize the beam as an empty list to store the generated API sequence, initialize the result buffer buff as an empty list to store the API sequence that has been generated and finished, and set the beam size to bs.

[0069] Step 45: Construct the initial "fraction-API sequence" tuple [0, " <sos>Add it to Beam.

[0070] Step 46: Repeat steps 47 to 424 on Beam until the maximum number of iterations T is reached or the number of pairs in results equals bs, then execute step 425.

[0071] Step 47: Initialize Beam′ as an empty list, iterate through each tuple [s, apiseq] in Beam, and perform steps 48 to 424 on it.

[0072] Step 48: Determine if apiseq ends with the "" tag. <eos>If the suffix is ​​", then add [s, apiseq] to results and return to step 47 to continue iterating over other pairs; otherwise, proceed to step 49.

[0073] Step 49: Use LLM to predict the probability distribution P of the next token to be generated for input and apiseq. This distribution describes the probability value of each lexical unit (token) in the vocabulary.

[0074] Step 410: Vocabulary Constraint Process: Initialize the candidate token set `tokens` to an empty set, and initialize the variable type buffer `buff` to a set of initially available variable types. The initial set of available variable types includes basic data types, the variable types of all static public members in the JDK, all variable types in the "java.lang" package, and all variable types that support autoboxing.

[0075] Step 411: Add the return values ​​of all generated APIs in apiseq to the buff.

[0076] Step 412: Set the boolean flag for the space character to False.

[0077] Step 413: Determine if apiseq is empty. If it is, proceed to step 414; otherwise, proceed to step 415.

[0078] Step 414: Initialize the API prefix to an empty string and proceed to step 418.

[0079] Step 415: Determine whether the last API in apiseq has been generated. If yes, proceed to step 416; otherwise, proceed to step 417.

[0080] Step 416: Initialize the API prefix to an empty string and set space to True, then proceed to step 418.

[0081] Step 417: Initialize the API prefix to the last API in apiseq that has not yet been fully generated, and then proceed to step 418.

[0082] Step 418: Iterate through each API in the knowledge base. For each API whose requirement variable type exists in the buff and has a prefix, execute steps 419 to 421. The API's requirement variable type includes all variable types in the API's parameter table. In addition, if the API is not a static method, the API's requirement variable type also includes the class, interface, enumeration, or record to which the API belongs.

[0083] Step 419: If space is True, add a space before API and proceed to step 420; otherwise, proceed directly to step 420.

[0084] Step 420: Remove the API prefix.

[0085] Step 421: Use the LLM tokenizer to perform tokenization and add the first token after tokenization to tokens.

[0086] Step 422: If space is True, add the end marker symbol "" to the generation process. <eos>Add it to tokens.

[0087] Step 423: Concatenate each token in tokens to apiseq to obtain a new candidate API sequence apiseq′. Calculate the score s′ for apiseq′ using the following formula, and add [s′, apiseq′] to Beam′:

[0088]

[0089] Where n is the length of the apiseq, P(token) is the probability value of the token output by the large language model, and s is the score of the apiseq.

[0090] Step 424: Sort all pairs in Beam′ from largest to smallest according to their scores, then keep only the top bs pairs in Beam′ and assign Beam′ to Beam.

[0091] Step 425: Output a recommended list of Beam as an API sequence.

[0092] Step 5: Optimize the API sequence recommendation list using knowledge-guided reordering.

[0093] After obtaining the recommended list of API sequences through knowledge-guided bundle search, knowledge-guided reordering is used to place API sequences in the recommended list that match the interface parameter types at a higher position. The specific steps are as follows:

[0094] Step 51: Iterate through each pair of results obtained in the knowledge-guided bundle search phase. Each pair contains a score s and an API sequence apiseq.

[0095] Step 52: Initialize the external dependency variable type set `rely` to an empty set.

[0096] Step 53: Set the variable type buffer buff to an empty set.

[0097] Step 54: Iterate through each API in apiseq and execute steps 55 to 58 for it until all APIs in apiseq have been traversed. Then, execute step 59.

[0098] Step 55: Iterate through each requirement variable type of the API and perform steps 56 and 57 for each type until all requirement variable types have been iterated. Then, execute step 58. The API's requirement variable types include all variable types in the API's parameter list. Additionally, if the API is not a static method, its requirement variable types also include the class, interface, enumeration, or record to which the API belongs.

[0099] Step 56: Determine if type exists in buff. If it does, proceed to step 58; otherwise, proceed to step 57.

[0100] Step 57: Add type to the repeat.

[0101] Step 58: Add the API's return value to the buff.

[0102] Step 59: Iterate through each variable type in `rely`, retrieve all direct or indirect inherited or implemented parent classes of that variable type from the knowledge base, and add these parent classes to `rely`.

[0103] Step 510: Determine if at least one variable in param has a type that does not exist in repeat. If so, multiply the score s in the current tuple by the multiplier r; otherwise, leave it unchanged.

[0104] Step 511: Reorder all pairs in results according to their scores in descending order.

[0105] Step 512: Output the apiseq tuples in the results in order as a recommended list of API sequences.

[0106] Example 1:

[0107] like Figure 5 As shown, taking the "java.io" package as an example, the API knowledge extraction process is introduced. First, the "Class Description" field of the API documentation for the "java.io" package is parsed, revealing that the package contains the "BufferedInputStream" class, the "Closeable" interface, and the "InputStream" class. Subsequently, a "contain" relationship is established between the package and the aforementioned classes or interfaces.

[0108] Next, the API documentation for the aforementioned classes or interfaces is parsed. Taking the "BufferedInputStream" class as an example, this process is as follows: First, the address of the API documentation for the "BufferedInputStream" class is obtained from the API documentation of the "java.io" package. Second, the "Implements" field in the documentation is parsed to obtain the interface "Closeable" implemented by the class; the "Field Details" field is parsed to obtain the member variable "buf" contained in the class; the "Constructor Details" field is parsed to obtain the constructor method "BufferedInputStream(InputStream)"; and the "Method Details" field is parsed to obtain the API method "read()" defined in the class. An "implementation" relationship is established between the "BufferedInputStream" class and the "Closeable" interface, and "contain" relationships are established between the "BufferedInputStream" class and the "buf" member variable, the "BufferedInputStream(InputStream)" constructor method, and the "read()" method, respectively.

[0109] Next, the "buf" member variable is parsed. This member variable is of type "byte[]" and has a protected access permission. Therefore, "type" is added between the member variable and the "byte" data type. <1> "Relationship (1 represents the dimension of the parameter), and set the "field" attribute of the member to "protected".

[0110] Finally, the `BufferedInputStream(InputStream)` constructor and the `read` method are analyzed. The analysis process for the `read` and `BufferedInputStream(InputStream)` methods is similar; this invention uses the `BufferedInputStream(InputStream)` constructor as an example. The parameter list of this constructor contains only one parameter, `InputStream`, and its access permission is "public". Therefore, a `parameter<0,0>` relationship is added between the constructor and the `InputStream` class, and the `field` attribute of the constructor is set to "public". Since the return value of a class's constructor can be considered as the class itself, a `return` statement is added between the constructor and the `BufferedInputStream` class. <0> "relation.

[0111] Example 2:

[0112] like Figure 6 As shown, the process of constructing training data is illustrated using the function `copyLarge` as an example. Each piece of training data in the training dataset contains three parts: a function description, interface parameter types, and an API sequence. First, the function annotation is used as the function description. Second, the parameter table of the method contains parameter types "InputStream", "OutputStream", and "byte[]", and these parameters are used as interface parameter types. Finally, all APIs called within the method body are sorted in order of appearance, i.e., "InputStream.read(byte[]) → OutputStream.write(byte[],int,int)", and these sorted APIs are used as the API sequence.

[0113] Example 3:

[0114] by Figure 7 Using training data as an example, this section introduces knowledge-guided data augmentation. First, the interface parameter types of the original data are cleared, i.e., set to "void," and the API sequence "File.listFiles(FileFilter)" is changed to "File.listFiles(FilenameFilter)." Next, the external parameters that the modified API sequence depends on are analyzed. Specifically, "File.isDirectory()" depends on the external parameter "File," and "File.listFiles(FilenameFilter)" depends on both "File" and "FilenameFilter." The parameter "File" that "File.delete()" depends on can be provided by the return value of "File.listFiles(FilenameFilter)," therefore this API does not depend on any other external parameters. Finally, "File" and "FilenameFilter" are added to the interface parameter types.

[0115] Example 4:

[0116] by Figure 8 This example illustrates knowledge-guided bundle search and knowledge-guided reordering. To enhance readability, the API parameter list is omitted in this instance. The specific settings for this example are: bundle size of 2; the knowledge base contains three API methods: "read.read", "file.file", and "file.read"; the output vocabulary of the large model contains "read", "file", ".", and " <e>"Four different tokens; the user query is "Read a file."; the interface parameter type is "file". The initial bundle list is empty, and the initial API sequence is..." <s>"And an initial score of 0 is added to the bundle list. First, a temporary bundle list is created and initialized to an empty list. Then, the user query and each API sequence in the bundle list are taken as input to the large model, at which point the large model outputs the probability value of each token in the vocabulary for the current input query and API sequence. Second, a set of candidate tokens (such as the initial API sequence) is constructed for the current API sequence by querying the knowledge base." <s>The candidate token set includes "read" and "file", and tokens not present in the candidate token set (such as those for the initial API sequence) will be excluded. <s>Tokens that do not exist in the candidate token set include "." and "". <e>The probability value of ") is set to 0. Then, each token from the vocabulary is concatenated to the current API sequence to obtain a new set of API sequences. The score of each API sequence is calculated and added to a temporary bundle list. Once all API sequences in the bundle list have been traversed, the bundle list is replaced with the temporary bundle list. The data in the temporary bundle list are sorted in descending order according to the API sequence scores, and only the top two API sequences are retained. This process is repeated until the fourth iteration, at which point all API sequences in the bundle list are set to "". <e>"At the end, the beam search process is complete."

[0117] Next, a knowledge-guided reordering process is performed. Specifically, it checks sequentially whether the demand variable type of each API sequence in the recommendation list matches the parameter variable type defined in the interface. Specifically, "read.read <e>The required variable type is "read", which is inconsistent with the parameter variable type "file" defined in the interface; "file.read" <e> The requirement variable type is "file", consistent with the parameter variable type "file" defined in the interface. If they match, the score of the API sequence is multiplied by 2; otherwise, it remains unchanged. Subsequently, the list is re-sorted to obtain a new recommendation list.< / e> < / e> < / e> < / e> < / s> < / s> < / s> < / e> < / eos> < / eos> < / sos> < / sep> < / sep> < / dim> < / dim>

Claims

1. A knowledge-guided, large language model-based trusted API recommendation method, characterized in that... The method includes the following steps: Step 1: Build an API knowledge base for APIRIP tasks. The specific steps are as follows: Step 11: Design the API ontology model. The concepts in the API ontology model include: basic data types, classes, interfaces, enumerations, records, APIs or methods, packages, and members; relationships include: inheritance, implementation, containment, and type. <dim>"、Return relation" <dim> "parameter"<idx,dim> "idx" represents the parameter index, and dim represents the dimension; attributes include: API, method, or member modifier "field"; values ​​include: public, private, protected, and static.< / dim> < / dim> Step 12: Using the requests tool, starting with the main page of the official Java JDK online documentation, recursively retrieve all API documentation pages and save these documentation pages as ".html" files; Step 13: Use BeautifulSoup to parse each ".html" file, and extract API entities, relations, attributes and values ​​from the corresponding fields according to the API ontology designed in Step 11, to obtain a set of triples consisting of "entity-relationship-entity" or "entity-attribute-value" triples; Step 14: Import all "entity-relationship-entity" and "entity-attribute-value" triples into the Neo4j graph database to obtain a graph-formatted API knowledge graph; Step 2: Construct a training dataset for the APIRIP task. The specific steps are as follows: Step 21: Search and download all Java projects on GitHub that have at least one star, and perform steps 22 to 24 for each Java project that meets the criteria; Step 22: Find all methods in the Java project that meet the following conditions: (1) have functional annotations; (2) only call JDK API methods. Step 23: For the first For a method that satisfies the conditions described in step 22, add a function comment to the method. As a functional description, the method's parameter list is used as an interface parameter type list. And parse out the API sequence according to the API sequence parsing rules defined in DeepAPI. ; Step 24: Combine the triples It is added to the APIRIP dataset as a training data point; Step 3: Use knowledge-guided data augmentation to fine-tune the large language model. The specific steps are as follows: Step 31: Perform steps 32 to 318 on each data point in the original APIRIP dataset to obtain the corresponding augmented data. Mix the obtained augmented data with the original dataset to obtain the augmented dataset. After performing data augmentation operations on each data point, proceed to step 319. Step 32: Initialization phase of data augmentation: Initialize the API index of the current traversal =0; the current available variable type cache This is a collection consisting of entities of type "base type", the variable types of all static public members, all entities contained in the "java.lang" package, and all entities that support encapsulation mechanisms; the currently searched API sequence. An empty list; the currently searched specified parameter An empty list; a list of currently found comments, specified variable types, and API sequence triples. An empty list; Step 33: Input the raw data for data augmentation, i.e., data containing functional descriptions. API sequence and interface parameter types The triple; let the current API index be denoted as . ; Let the currently available variable type cache be . Let the enhanced API sequence be ; ; Let the enhanced interface parameter type be ; Let the enhanced annotations, specified variable types, and API sequence triple lists be denoted as ; Let the API knowledge base be... ; Step 34: Determine Does the size exceed the specified threshold? Return if it exceeds the limit. Otherwise, proceed to step 35; Step 35: Determine Is it equal to If the length is specified, proceed to step 36; otherwise, proceed to step 39. Step 36: Determine Whether or not If they are exactly the same, it means that duplicate data has been generated, which should be discarded and the result returned directly. Otherwise, proceed to step 37; Step 37: Calculate using the following formula fractions : in, The length of the API sequence; Refers to the API knowledge base Retrieve the return value type of a given API; Refers to the API knowledge base Retrieve a given set of requirement variable types for a single API or a sequence of APIs; Step 38: Combine the triplet Add to In, and return ; Step 39: Traverse the API knowledge base Each overload form And execute steps 310 to 317; Step 310: Let equal ; Step 311: Protect the scene, , , and Backup to the cache; Step 312: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require In but not existing Add the variable type to middle; Step 313: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require the full context.] The return value, along with its directly or indirectly inherited or implemented classes, interfaces, enumerations, or records, are added to... middle; Step 314: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require Add to middle; Step 315: Let And by recursively executing step 33, we obtain ; Step 316: Restore the scene, , , and Restore to the backup in the cache; Step 317: If If all overloaded forms have been traversed, then return. Otherwise, return to step 39 and continue iterating. Other overload configurations; Step 318: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require All of them Triples based on Sort the elements in ascending order and output the top-ranked elements. of Data pairs, and respectively with constitute A new piece of data; Step 319: Fine-tune the LLM using the enhanced dataset: For Training data in the form of and by" <sep>"After being concatenated as a separator, it is used as the model input." As the expected output, the LLM is fine-tuned directly using the fine-tuning methods provided by the LLM itself.< / sep> Step 4: Generate an API sequence recommendation list using knowledge-guided bundle search. The specific steps are as follows: Step 41: Obtain a list of interface parameter types by parsing the interface definition in the user's development environment. ; Step 42: Enter a text description of the user's desired functionality. ; Step 43: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require the and by" <sep>The input is constructed by concatenating characters as separators. ;< / sep> Step 44: Initialization phase of beam search: Set the beam Initialize as an empty list to store the generated API sequence, and set the result buffer. Initialize as an empty list to store the completed API sequences, and set the bundle size to [value]. ; Step 45: Construct the initial "fraction-API sequence" tuple [0, <sos>], and add it to middle;< / sos> Step 46: Loop through the pairs Execute steps 47 to 424 until the maximum set number of loops is reached. or The number of pairs in the middle is equal to Then proceed to step 425; Step 47: Initialization Iterate through an empty list. Each pair in Perform steps 48 to 424 on it; Step 48: Determine Should it be marked with an end tag? <eos>" is a suffix, then it will be Join If the process fails, return to step 47 and continue iterating through other pairs; otherwise, proceed to step 49.< / eos> Step 49: Utilize LLM for and Predict the probability distribution of the next token to be generated This distribution describes the probability value of each lexical unit token in the vocabulary; Step 410: Vocabulary Constraint Process: Set the candidate tokens Initialize to an empty set and set the variable type buffer. Initialize to a collection of initially available variable types; Step 411: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require Add the return values ​​of all generated APIs to middle; Step 412: Remove the Boolean flag for the space character. Set as ; Step 413: Determine If the value is empty, proceed to step 414; otherwise, proceed to step 415. Step 414: Prefix the API Initialize to an empty string and proceed to step 418; Step 415: Determine If the last API in the process has been generated, proceed to step 416; otherwise, proceed to step 417. Step 416: Prefix the API Initialize to an empty string, and Set as Proceed to step 418; Step 417: Prefix the API Initialize to For the last API that has not been fully generated, proceed to step 418; Step 418: Traverse every API in the knowledge base, and for each requirement variable type, it exists in... The prefix is All APIs can execute steps 419 to 421; Step 419: If for If the condition is met, add a space before the API and proceed to step 420; otherwise, proceed directly to step 420. Step 420: Remove the API prefix ; Step 421: Perform word segmentation on the data using the LLM tokenizer, and add the first token after word segmentation to the... middle; Step 422: If for The end marker for the generation process is " <eos>Join middle;< / eos> Step 423: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require the full context.] Each token in the array is concatenated to the array. Then, a new candidate API sequence is obtained. The formula is as follows: Calculate fractions and will [ Add to middle: Where n is the constituent Length, Output for large language models The probability value, for The score; Step 424: [The sentence is incomplete and requires more context to be translated accurately.] All pairs are sorted in descending order of score, and then only the pairs are retained. China ranked top The binary pair, and Assign to ; Step 425: Output Recommended list as an API sequence; Step 5: Optimize the API sequence recommendation list using knowledge-guided reordering. The specific steps are as follows: Step 51: Traverse the elements obtained in the knowledge-guided bundle search phase Each pair in the list contains a score. and API sequence ; Step 52: Initialize the set of external dependency variable types It is an empty set; Step 53: Cache the variable type Set to an empty set; Step 54: Traverse sequentially For each API in the list, perform steps 55-58 on it until all APIs have been traversed. All APIs in the list, then proceed to step 59; Step 55: Iterate through each requirement variable type in the API. and to Execute steps 56 and 57 until every requirement variable type has been traversed. Then, proceed to step 58; Step 56: Determine Does it exist in If yes, proceed to step 58; otherwise, proceed to step 57. Step 57: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require the Add to middle; Step 58: Add the API's return value to middle; Step 59: Traverse For each variable type in the database, retrieve all direct or indirect inherited or implemented parent classes of that variable type from the knowledge base and add these parent classes to the database. middle; Step 510: Determine Does at least one variable type not exist in the table? If so, then the scores in the current pair will be... Multiply by a factor Otherwise, remain unchanged; Step 511: For All pairs are reordered in descending order of their scores; Step 512: Output in sequence In the middle binary Recommended list as an API sequence.

2. The knowledge-guided, large language model-based trusted API recommendation method according to claim 1, characterized in that... In step 37, the required variable types of the API include all variable types in the API's parameter table. If the API is not a static method, then the required variable types of the API also include the class, interface, enumeration, or record to which the API belongs.

3. The knowledge-guided, large language model-based trusted API recommendation method according to claim 1, characterized in that... In step 410, the initial set of available variable types includes basic data types, variable types of all static public members in the JDK, all variable types in the "java.lang" package, and all variable types that support autoboxing.

4. The knowledge-guided trusted API recommendation method based on a large language model according to claim 1, characterized in that... In step 418, the required variable types of the API include all variable types in the API's parameter table. If the API is not a static method, then the required variable types of the API also include the class, interface, enumeration, or record to which the API belongs.

5. The knowledge-guided trusted API recommendation method based on a large language model according to claim 1, characterized in that... In step 55, the required variable types of the API include all variable types in the API's parameter table. If the API is not a static method, then the required variable types of the API also include the class, interface, enumeration, or record to which the API belongs.

Images