Modular software library for use with large language models to generate code

Abstract

Disclosed herein are systems, apparatuses, and methods for configuring and using one or more modular software libraries for use with large language models (LLMs) for automatically generating code from one or more user task queries. The systems, apparatuses, and methods compare a user's task query to generate code for a task with only headers of docstring. After identifying potentially relevant code from the most closely matching headers, the systems, apparatuses, and methods combine the user's task query with the identified docstring bodies as a prompt to one or more LLMs to converge upon software modules, functions, classes, and / or submodules (e.g., software code components) that contain relevant code. The systems, apparatuses, and methods then generate code responsive to the user's task query from the selected modules, functions, classes, and submodules.

Description

MODULAR SOFTWARE LIBRARY FOR USE WITH LARGE LANGUAGE MODELS TO GENERATE CODEBACKGROUND

[0001] Recently, Large Language Models (“LLMs”) have shown promise in generating code for user-requested tasks. Prompting LLMs to write code for tasks often requires asking the LLM to use one or more software libraries. The prompts often specify the desired task, data operations, and / or data visualizations. LLMs are trained using libraries of open source code such that the LLMs output certain combinations of the code in response to the prompt.

[0002] A known issue is the limitations of open source libraries and the ability of LLMs to generate complex code from these code libraries. Many open source libraries contain tens of thousands of code modules, functions, classes, and submodules, which may or may not be linked. Further, the libraries often contain code with idiosyncratic patterns for different tasks, dependent components, and multi-hundred-line scripts to complete tasks. Current LLMs identify a few modules, functions, classes, and submodules for generating relatively small scripts in response to prompts. However, these known LLMs have difficulty creating more complex code due to difficulties identifying relatively more modules, functions, classes, and submodules to satisfy a prompt. In other words, known LLMs cannot handle the complexity of putting retrieved pieces of code together in the correct manner. Instead, LLMs either generate highly-error prone code or coverage upon a small set of modules, functions, classes, and submodules that are inadequate to correctly complete the requested task.

[0003] In addition to above, LLMs only have access to certain code libraries. If a code library is not available, the LLMs cannot use code from this library. Many companies and organizations have their own proprietary code that they prefer to keep private from LLMs. Instead of making the code available, the companies provide the LLMs the library and / or code documentation, which is typically done through a process called Retrieval-Augmented Generation (“RAG”). The code documentation can include tens to hundreds of lines of code for each separate module, function, class, or submodule. Current LLMs have difficulty matching prompts to significant amounts of documentation, resulting sometimes in the incorrect selection of code.

[0004] A need accordingly exists for a modular software library that is more easily searchable by LLMs to converge upon the most appropriate code for fulling prompts.SUMMARY

[0005] Disclosed herein are systems, apparatuses, and methods for configuring and using one or more modular software libraries for use with LLMs for automatically generating code from one or more user task queries. The systems, apparatuses, and methods are configured in a generic, task-agnostic framework that uses one or more well-structured software libraries to overcome the above-discussed problems. The disclosed framework provides a balance between being able to handle a range of complex tasks and workflows to cover virtually all use cases while being simple and uniform enough across each of the possible use cases such that any task is handled with no more than one hundred to two hundred lines of code.

[0006] The disclosed library framework ensures that the logical complexity of the code does not exceed the logical complexity that LLMs are able to handle with minimal error. To achieve this balance, one or more code libraries are configured such that the modules, functions, classes, and submodules are highly modular, interoperable, decoupled, and relatively small (in terms of the functionality they each address), thereby fitting together in a seamless manner. In accordance with aspects of the present disclosure, when a LLM encounters a task and is given information about the library components, the disclosed computing systems and methods may enable the LLM to select the few components it needs and seamlessly stitch them together end-to- end to create a fully-functional, executable script, rather than concerning itself with implementing the lower-level details that are taken care of by the code modules.

[0007] In some aspects, the disclosed library may be configured such that code documentation (referred to herein as docstring) for each of the modules, functions, classes, and submodules (referred to herein as software code components) may be separated into a header and a body. The header includes one or more lines of docstring that provides a general description of functionality of a respective software code component. The body includes a plurality of lines of docstring that detail arguments, types, and intended functionality of the respective software code component. In some instances, a separate data structure may store a copy of the headers and links or references to the corresponding software code components.

[0008] The use of the headers in the disclosed framework enables LLMs to more efficiently and accurately match text from a user task query to one or more software code components. Instead of having to analyze tens to hundreds of lines of docstring corresponding to the entire docstring, the LLMs only have to analyze a few lines of code for each header. Since the headers provide a concise summary of the functionality of the respective software code component, the matches are more efficient and accurate compared to analyzing entire docstring bodies, which may include documentation that at least partially obfuscates the purpose of the code.

[0009] In an embodiment, the disclosed computing systems, methods, and apparatuses may be configured to receive a task query from a user device. The task query may specify a task or a request for code to be generated. The systems, methods, and apparatuses may be configured to use one or more LLMs to compare the task query to headers of software code components in a library. The one or more LLMs may perform semantic matching between the task query and the headers and identify a certain number of matching headers. In some instances, the number of matches may be based on the complexity of the task query. Further, in some instances, the systems, methods, and apparatuses are configured to parse a task query into sub-task queries to conduct more targeted semantic matching to docstring headers. In these instances, the systems, methods, and apparatuses may be configured to identify and parse relatively long or complex task queries.

[0010] After the semantic comparisons are complete and matching headers are identified, the systems, methods, and apparatuses then select a first set of the software code components that correspond to the semantically matching headers. The systems, methods, and apparatuses next combine the docstrings of the first set of the software code components with the task query to create an LLM prompt. The systems, methods, and apparatuses then perform another iteration of semantic matching. In this iteration, the systems, methods, and apparatuses select a second set of the software code components by semantically comparing the prompt to the header and body of each of the software code components that are included within the first set. Thus, after converging upon a first set of matching software code components, the systems, methods, and apparatuses perform another semantic match using the entire docstrings to further narrow the search results. Since the initially identified software code components in the first set are already relevant to the original task query, there is less of a chance that the docstring body will obfuscate the results. Rather, the comparisons between the different docstring bodies at this iteration enables thesystems, methods, and apparatuses to converge upon the software code components that will satisfy the task provided by the prompt.

[0011] After the software code components are selected during the second iteration of semantic matching, the systems, methods, and apparatuses are configured to use the selected software code components to generate code for satisfying the specified task. Since the software code components are modular, they can be relatively easily combined together by the LLMs used by the systems, methods, and apparatuses. After the code is generated, the systems, methods, and apparatuses provide the code to the user device.

[0012] In another embodiment, the systems, methods, and apparatuses are configured to utilize the hierarchal nature of the software code components between modules, functions, classes, submodules, etc. Instead of analyzing docstring headers of all the software code components during the first semantic search, the systems, methods, and apparatuses are configured to only analyze headers of modules. After matching modules are identified, the systems, methods, and apparatuses next analyze and fetch semantically matching functions of selected modules. The systems, methods, and apparatuses perform further semantic matching for classes of matched functions and submodules of matched classes. The systems, methods, and apparatuses perform these lower-level matches until the base software code components are reached. The systems, methods, and apparatuses then combine the identified base software code components (and higher ordered components as needed) to generate the code.

[0013] In light of the present disclosure and the above aspects, it is therefore an advantage of the present disclosure to semantically match headers of docstring to task queries to more efficiently identify relevant software code components from a code library.

[0014] It is another advantage of the present disclosure to create a well-structured code library in which docstring is partitioned into headers and bodies.

[0015] Additional features and advantages are described in, and will be apparent from, the following Detailed Description and the Figures. The features and advantages described herein are not all-inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the figures and description. Also, any particular embodiment does not have to have all of the advantages listed herein and it is expressly contemplated to claim individual advantageous embodiments separately. Moreover, it should benoted that the language used in the specification has been selected principally for readability and instructional purposes, and not to limit the scope of the inventive subject matter.BRIEF DESCRIPTION OF THE FIGURES

[0016] Fig. 1 illustrates a known prior art process for generating code using a large language model.

[0017] Figs. 2 and 3 illustrate processes for generating code using a large language model, according to example embodiments of the present disclosure.

[0018] Fig. 4 illustrates a system using the process of Figs. 2 and 3 to generate code using a large language model, according to an example embodiment of the present disclosure.

[0019] Figs. 5 and 6 illustrate software code components, according to example embodiments of the present disclosure.

[0020] Fig. 7 illustrates lines of code including a header and body of a software code component, according to example embodiments of the present disclosure.

[0021] Fig. 8 illustrates how the process of Figs. 2 and 3 identify a docstring within a software code component, according to example embodiments of the present disclosure.DETAILED DESCRIPTION

[0022] Disclosed herein are systems, apparatuses, and methods for configuring and using one or more modular software libraries for use with LLMs for automatically generating code from one or more user task queries. The systems, apparatuses, and methods compare a user’s task query to generate code for a task with only headers of docstring. After identifying potentially relevant code from the most closely matching headers, the systems, apparatuses, and methods combine the user’s task query with docstring bodies to form a prompt for one or more LLMs to converge upon software modules, functions, classes, and / or submodules (e.g., software code components) that contain relevant code. The systems, apparatuses, and methods then generate code responsive to the user’s prompt from the selected modules, functions, classes, and submodules.

[0023] The systems, apparatuses, and methods disclosed herein provide accuracy and efficiency advantages over known LLM code generation systems by first using only the docstring headers, which provide a concise summary of the corresponding modules, functions, classes, and submodules. In comparison, known LLM systems use a RAG approach, which uses an auxiliarysoftware stack where full documentation (e.g., docstrings) is uploaded to a data structure, known as a vector database. In a vector database, documentation for each of the software code components is embedded into a continuous mathematical representation of vectors. Then, when a user makes a request to generate code, the request itself is embedded, and a similarity metric, such as cosine similarity, is used to select the parts of the documentation that most closely “match the meaning” of the user’s request. For instance, a user makes a request to generate code. In response, known LLMs locate the relevant parts of the codebase documentation (e.g., the parts of the documentation whose semantic embedding most closely resembles that of the user’ s request). That documentation is then appended to the user’s request as the full prompt for generating code.

[0024] In addition to the above issues, it is often difficult to set up a RAG system. It is time consuming to identify and upload the documentation and software code to the RAG system. Further, there is a chance that some documentation or software code may be omitted given the manually intensive process of setting up the RAG system. Moreover, performing a similarity match of vectors is computationally intensive.

[0025] Fig. 1 illustrates a known prior art process 100 for generating code using an LLM. The process 100 begins when a code documentation library is created and / or updated in a data structure (block 102). The known system performs a chunking and / or embedding process (block 104) where the code documentation is converted or embedded as vectors defined by mathematical representations of words in a high-dimensional space (block 106). The vectors are stored to a database for later use.

[0026] As shown in Fig. 1, a known LLM orchestrator system later receives a task query from a user device (block 108). The known orchestrator system then uses an embedding process (block 110) to create a continuous mathematical representation of a vector corresponding to the task query, which is referred to as an embedded task (block 112). The known LLM orchestrator system then performs an embedding similarity search using, for example a cosine similarity comparison, to compare the vectors of the documentation to the vector of the embedded task (block 114). The comparison includes, for example, calculating distance between documentation vectors and the task vector. The known LLM orchestrator system selects vectors of the documentation that most closely matches the task vector (e.g., the vectors that have the closest distance to the task vector).

[0027] The known LLM orchestrator system of Fig. 1 identifies documentation that is associated with the selected vectors (block 116). The LLM system then creates an LLM prompt by combining the selected documentation with the original task request (block 118). In technical terms, an LLM prompt generally refers to a sequence of tokens (textual inputs) that serves as the initial conditioning context for an LLM’s autoregressive generation process. The prompt may define the input sequence upon which the model applies its learned probability distribution P(y\x), where x is the prompt and y is the predicted continuation. Prompt may influence the activation of specific patterns within an LLM’s parameters, effectively determining the output based on the encoded linguistic and semantic cues. The known LLM orchestrator system passes the prompt to known LLMs for selecting software code components (block 120). The known LLMs create code from the selected software code components, which is provided to the user in response to the task query (block 122). To create the code, the known LLMs analyze the documentation and task query to determine how certain software modules, functions, classes, and / or submodules are to be combined to arrive at the requested task. This includes using calls and links between the different code components. Code may generally refer to source code written in programming languages such as general-purpose languages (Python, JavaScript, Java, C++, Go, etc.), markup / config languages (HTML, CSS, YAML, JSON), query languages (SQL, GraphQL), scripting languages (Bash, PowerShell), domain-specific languages (Regex, Terraform, etc.). The type of code an LLM generates may depend on the prompt it receives.

[0028] There are issues with known LLM orchestrator systems for generating code. Oftentimes code documentation libraries are complex and use different idiosyncratic patterns for different tasks. In addition, the code libraries contain dependent software code components that comprise multi-hundred-line scripts. Known LLMs cannot handle the logical complexity of putting the retrieved pieces of software code components together in the correct manner and may generate highly-error-prone and incorrect code.

[0029] Additionally, there are known code retrieval issues. There is a possibility that incorrect or incomplete parts of code are retrieved since the vector distances or similarities are computed via distances in the latent space of semantic embeddings. Further, semantic relevance between a task query and the code available may not always be reflective of the desired task-code compatibility. In some instances, the mathematical representation of extensive text from the documentation in the vector may make it harder to match to a task query vector. Alternatively,extensive documentation may be represented as a relatively large vector that partially matches many task vectors. This means the known LLM orchestrator systems may over-select code, thereby creating larger, more inefficient scripts.

[0030] While some LLMs now provide 128k-token context windows, attention scores (e g., the numbers transformer-based LLMs use to attach saliency to information) are spread out more across a longer context, and therefore the LLM may still not give enough attention to the relevant parts of the codebase, or give attention to code components not needed, simply due to the higher likelihood of that happening when more information is present. The more information is held in the LLM’s context window, the more information the LLM has to process and spread its attention scores over, possibly leading to subpar retrieval. Furthermore, another benefit of the disclosed two-step approach is cost. Known LLM providers charge per-token. Supplying docstring headers and then full docstrings for only the components selected is significantly less input tokens than supplying the full documentation of the whole library.

[0031] The systems, apparatuses, and methods overcome the above noted issues by making the initial retrieval of code more efficient. Instead of searching entire docstrings, the systems, apparatuses, and methods provide an LLM orchestrator server or computing system that interfaces with a code library in which documentation for software code components is partitioned into headers and bodies. The headers are provided in the first few lines of a docstring and provide a high-level, general description of the functionality of the software code component. The body of the docstring provides arguments, types, and intended functionality of the software code component.

[0032] Typically, docstrings are used by an external documentation generator to build the official end-user documentation for a library. The systems, apparatuses, and methods compare headers of the docstrings to a user task query using semantic matching. The systems, apparatuses, and methods identify the software code components that correspond to the matching software code components. The systems, apparatuses, and methods next combine the entire docstring with the task query as a prompt to one or more LLMs for generating code. Rather than semantically matching the user request to the lengthy, full documentation via embeddings, which can be highly error-prone, the systems, apparatuses, and methods perform a two-step process where one or more LLMs are supplied with short, high-level descriptions of what is available in the library, and then once it makes the LLM(s) makes selections, the systems, apparatuses, and methods follow up withthe details of the selected components as part of a prompt to one or more LLMs for generating code.

[0033] Reference is made herein to software modules, functions, classes, and submodules as software code components. It should be appreciated that the systems, apparatuses, and methods disclosed herein can be used for retrieving any type of software components including methods, objects, packages, etc. The software code components may have predefined modular functionalities that facilitate interoperability and cross-code connectivity to enable scripts to be generated having relative few lines of code (e.g., between ten to two hundred lines of code). Further, each of the software code components have a well-defined docstring structure comprising a header and a body.Example LLM Orchestrator Server Processes

[0034] Fig. 2 is an example process 200 performed by an LLM orchestrator server disclosed herein for generating code from one or more task queries, according to an example embodiment of the present disclosure. The example process 200 may be carried out by, for example, a server and / or an LLM orchestrator server described in conjunction with Fig. 4. Although the process 200 is described with reference to the flow diagram illustrated in Fig. 2, it should be appreciated that many other methods of performing the functions associated with the process 200 may be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the blocks described are optional.

[0035] The example process 200 begins when software code components are loaded and / or updated in a code library or database (block 202). The software code components each comprise executable code and a docstring, each docstring including a header and a body. A header may generally refer to a one-line summary of what the object (function, class, etc.) does. A body of a docstring may follow after the header and include a more detailed explanation, arguments, return value, exceptions, and usage examples. The example LLM orchestrator server performs a docstring retrieval process (block 204). Specifically, the LLM orchestrator server analyzes each of the docstrings to identify headers. In some embodiments, the LLM orchestrator server also identifies the body of the software code component. The LLM orchestrator server next makes the docstring headers available for semantic matching (block 206).

[0036] In some embodiments, the LLM orchestrator server is configured to create a data structure or file with a copy of the docstring headers. Each header may include a link or pointerto the corresponding header in the docstring of the software code component. Additionally or alternatively, the headers may be stored in a cache memory of the LLM orchestrator server.

[0037] As shown in Fig. 2, a task query is received by the LLM orchestrator server from a user device (block 208). The task query specifies a user request to automatically create a software script, functions, data operations, and / or data visualizations. The LLM orchestrator server semantically matches the docstring headers to the task query (block 210). The LLM orchestrator server may use one or more LLMs to perform the semantic matching. In some embodiments, the LLM orchestrator server extracts information from the task query in addition to creating an abstraction of the task query. The LLM orchestrator server may combine the extracted info with the abstraction as an input to the one or more LLMs.

[0038] The LLM orchestrator server receives information indicative of the closest semantically matching headers from the one or more LLMs. The LLM orchestrator server uses the information from the one or more LLMs to select a set of the software code components (block 212). The information may include the closest matching headers, identifiers of the software code components that correspond to the closest matching headers, and / or links to the software code components that correspond to the closest matching headers. The LLM orchestrator server uses the received information to select entire docstrings of the software code components that correspond to the closest matching headers (block 214).

[0039] The example process 200 of Fig. 2 continues by the LLM orchestrator server combining the task query with the selected docstrings (block 216) to create a prompt (block 218). The LLM orchestrator server provides the prompt to one or more LLMs for generating the software code (block 220). This may include selecting a (second) set of the software code components by semantically comparing the prompt to the header and body of each of the software code components that are included within the prompt. In this instance, the code is generated from the second set of the software code components. In other instances, the one or more LLMs generate the code from the prompt without selecting another set of software code components.

[0040] To generate the code, the one or more LLMs determine which of the docstrings most closely matches the task query included within the prompt using, for example semantic matching. The LLM(s) then identify software code components that correspond to the most closely matching docstrings. The LLM(s) are configured to use calls and linkages between the selected software code components to construct code or a script. In some embodiments, theLLM(s) use a hierarchy of the software code components to create logical ordering. Since each of the software code components are highly modular, interoperable, decoupled, and relatively small (in terms of the functionality they each address), the LLM(s) are able to fit the selected software code components together in a seamless manner. The LLM orchestrator server receives the generated code or script from the one or more LLM(s) (block 222). In response, the LLM orchestrator server transmits or otherwise provides the generated code and / or script to the user device in response to the task query. The example process 200 may then conclude. Separate sessions of the process 200 may be invoked by the LLM orchestrator server for each task query received.

[0041] In some embodiments, the LLM orchestrator server described herein is configured to retrieve docstring headers in a depth-first / breadth-first search manner. Fig. 3 illustrates an example process 300 performed by the LLM orchestrator server for generating code from one or more task queries using a hierarchical configuration of the software code components, according to an example embodiment of the present disclosure. In this embodiment, block 204 is performed recursively for lower-level software code components (block 302). The LLM orchestrator server uses the one or more LLMs to perform a first semantic match of the task query to headers of software modules of the software code components. The LLM orchestrator server then performs a second semantic match of the task query to headers of software functions of the software code components that are contained within the closest matching headers of the software modules. In other words, the LLM orchestrator server first determines relevant modules, and then only searches headers of software functions within the relevant modules. The LLM orchestrator server may perform a third semantic match of the task query to headers of software classes of the software code components that are contained within the closest matching headers of the software functions. Further, the LLM orchestrator server may perform a fourth semantic match for lower-level software code components until identifying base code components. The LLM orchestrator server then selects a set of the software code components that correspond to the closest matching lowest level components. In some instances, the LLM orchestrator server selects higher-level components as needed to retain software operability. Such a configuration ensures that less software components with fewer lines of code are added to the prompt for generating the requested script.

[0042] It should be appreciated that the processes 200 and 300 of Figs. 2 and 3 remove the possible error introduced by the embeddings discussed in conjunction with Fig. 1. Further, as long as the code library and docstrings follow the proposed structure, functionality can be added or removed from the code library without having to explicitly reference or update anything on the side of the LLM since the full docstring retrieval and augmentation process happens at runtime, not at compile time or during static analysis. Accordingly, the software code components that are included in the code library will be seen by one or more LLMs. As such, the more modular the code library is, the more granular the context LLMs can receive and process.Example Modular Code Generation System

[0043] Fig. 4 illustrates a modular code generation system 400 using the process 200 and 300 of Figs. 2 and 3 to generate code using one or more LLMs, according to an example embodiment of the present disclosure. The example system 400 includes a LLM orchestrator server 402, a memory device 404, and a code library 406. The LLM orchestrator server 402 is communicatively coupled to the memory device 404 and the code library 406 via a network or a local area connection. In some embodiments, the LLM orchestrator server 402 may be configured in a cloud-based computing environment in conjunction with the memory device 404 and the code library 406. In some instances, the code library 406 may be integrated or included with the memory device 404.

[0044] As shown in Fig. 4, the LLM orchestrator server 402 may include, host, train, or connect with one or more LLMs 408a and 408b. In the illustrated example, LLMs 408a may be configured to perform semantic matching of a task query provided by a user to docstring headers. Further, LLMs 408b may be configured to generate code based on a prompt that incorporates the task query with docstrings of software code components with matching headers. In some embodiments, the same LLMs 408a or 408b may perform semantic matching and generate code.

[0045] The example code library 406 includes software code components 410. Each of the software code components 410 includes executable code and a docstring. Each docstring includes a header and a body. As discussed above, the LLMs 408a in conjunction with the LLM orchestrator server 402 access the software code components 410 in the code library 406 to semantically match the docstring headers to a user’s task query. Further, when the LLMs 408b receive the prompt to generate code, the LLMs 408b in conjunction with the LLM orchestratorserver 402 access the software code components 410. While the prompt includes the docstring, the LLMs 408b are configured to use the docstring to determine which of the software code components 410 are relevant for generating the requested code. After identifying the relevant docstring and any linkages and / or interconnections, the LLMs 408b access the corresponding executable code from the code library 406. The LLMs 408b use the relevant docstrings in conjunction with the acquired executable code to determine how the modular code components are stitched together in a seamless manner.

[0046] In some embodiments, the memory device 404 may be used to store docstring headers. In these embodiments, the LLMs 408a in conjunction with the LLM orchestrator server 402 access the docstring headers from the memory device 404 instead of reading the headers from the software code components 410. The docstring headers may be stored in a data structure 412 within the memory device 404. The LLM orchestrator server 402 may create and / or update the data structure 412 by periodically scanning the software code components 410 in the code library 406 for docstring headers. The identified headers are stored to the data structure 412 in conjunction with a link, reference, or pointer to the corresponding software code components 410. In some instances, the memory device 404 may be a cache memory where the LLM orchestrator server 402 creates the data structure 412 daily, weekly, or hourly. The LLM orchestrator server 402 may receive indications when code is changed in the code library 406 and update the data structure 412 accordingly.

[0047] The modular code generation system 400 of Fig. 4 also includes a user device 420, which may include a laptop computer, a desktop computer, a workstation, a tablet computer, a smartphone, etc. The user device 420 is communicatively coupled to the LLM orchestrator server 402 via a network 422, which may include any wide area network (e.g., the Internet), any cellular network, or combinations thereof. The LLM orchestrator server 402 includes an interface 424 for communicating with the user device 420. The interface 424 may include one or more application programming interfaces (“APIs”) for receiving query tasks and returning generated code. The interface 424 may additionally or alternatively include a web interface for communicating with one or more web pages displayed at the user device 420.

[0048] The user device 420 may include an application 426 for enabling a user to enter a task query and provide generated code. The application 426 may include a web browser and / or asoftware app. The application 426 is configured to communicate with the interface 424 of the LLM orchestrator server 402.

[0049] In the illustrated example, the application 426 receives a task query 428 from a user. The application 426 transmits the task query 428 to the interface 424 of the server 402 via the network 422. The LLM orchestrator server 402 in conjunction with the LLMs 408 perform the process 200 and / or 300 to generate code 430. The LLM orchestrator server 402 then transmits or otherwise provides the generated code 430 to the application 426. In some instances, the LLM orchestrator server 402 stores a copy of the generated code 430 in conjunction with the task query 428, which may be used to provide a faster response when the same or similar task queries are received.

[0050] Figs. 5 and 6 illustrate software code components 410, according to example embodiments of the present disclosure. As disclosed herein and shown in Figs. 5 and 6, the software code components 410 include a plurality of modules, functions, classes, and submodules. Each module may have one or more functions. Further, each function may have one or more classes. Additionally or alternatively, some functions may call each other or be sub-functions of other functions. Fig. 5 shows a hierarchical structure between the software code components 410, where classes are the base code components. Here, there are separate instances of the same function for multiple modules. For instance, Module A, Module B, and Module C each include a separate Function A.

[0051] Fig. 6 shows a list-type structure, where modules are sequentially listed, followed by functions and classes. In this embodiment, Modules A, B, and C may each link to Function A. However, there is only one instance of Function A. Either of the structures shown in Fig. 5 or 6 provides modular software code components.

[0052] Fig. 7 illustrates lines of code including a header 702 and a body 704 of a software code component 410 (e.g., including one or more software modules, software functions, software classes, and software submodules), according to example embodiments of the present disclosure. Together, the header 702 and the body 704 form a docstring for the executable code. In some embodiments, a header of the present disclosure may include one or more lines of the respective docstring that provides a general description of functionality of the respective software code component. Further, a body of the present disclosure may include a plurality of lines of the respective docstring that detail arguments, types, and intended functionality of the respectivesoftware code component. According to some implementations, each of the software code components may be configured to contain less than 150 to 100 lines of code, and the software code components may be programmed in at least one of Python, C#, C++, or JavaScript. Fig. 7 shows a class method for a geometry class to sample points from an interior of a geometry. The docstring header 702 here is the single line “Sample points from the interior of the geometry.” This is a simple, high-level description of the software code component 410 (i.e., class method here). The software code components 410 available to the LLM 408a have such a docstring. When selecting which software components to use, the LLM 408a first receives the headers only of all software code components 410 available in the code library 406, along with the user’s task query 428. The LLM 408a may be queried (with no additional training) to select the necessary components based on the docstring headers alone (along with additional contextual information to help its selection). Once the LLM 408a makes its selection, the selected software code components 410 are then queried for their full docstring (including header 702 and body 704) (i.e., everything between the two sets of triple-quotes), describing exactly how to use the component. If, for a particular problem, the LLM 408a decides it needs the sample interior method, it will include “sample interior” in its selection.

[0053] Fig. 8 illustrates how the processes 200 and 300 of Figs. 2 and 3 identify a docstring within a software code component, according to example embodiments of the present disclosure. In the illustrated example, the header 702 includes text after executable code. The header 702 includes a single-line description that is before arguments that are summarized by the body 704 of the docstring. The definition of the variables within the arguments may be associated with body text. Further, return information is also associated with the body 704. The LLM 408a may be configured to identify only the header 702 between the executable code and body 704 with the arguments and return information.

[0054] It should be appreciated that the systems, methods and procedures described herein may be implemented using one or more computer programs or components. The programs of the components may be provided as a series of computer instructions on any computer-readable medium, including random access memory (“RAM”), read only memory (“ROM”), flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions may be configured to be executed by a processor, which when executing the series of computerinstructions performs or facilitates the performance of all or part of the disclosed methods and procedures.

[0055] It should be understood that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.

Claims

CLAIMS1 . A system including: an interface communicatively coupled to a user device via a network; a memory device storing: a library of software code components, each of the software code components including executable code and one or more docstrings, each docstring including a header and a body, and a data structure including one or more headers of the one or more docstrings for the software code components included within the library; and a computing server device communicatively coupled to the memory device and the interface, the computing server device including a large language model that is trained to generate codes, which when executed by the computing server device, causes the computing server device to: receive a task query from the user device via the interface, the task query specifying a task or code to be generated, use the task query and the data structure to select headers that semantically match the task query, select a first set of the software code components by identifying the software code components that correspond to the headers, create a prompt by combining the one or more docstrings of the first set of the software code components with the task query, select a second set of the software code components by semantically comparing the prompt to the header and body of each of the software code components that are included within the first set, generate the code based on the second set of the software code components, and provide the code generated to the user device.

2. The system of Claim 1, wherein the software code components comprise software modules, software functions, software classes, and software submodules.

3. The system of Claim 1, wherein the header includes one or more lines of a respective docstring that provides a general description of functionality of the respective software code component.

4. The system of Claim 1, wherein the body includes a plurality of lines of a respective docstring that detail arguments, types, and intended functionality of the respective software code component.

5. The system of Claim 1 , wherein each of the software code components is configured to contain less than 150 to 100 lines of code.

6. The system of Claim 1, wherein each of the software code components is configured to be modular, interoperable, and decoupled to enable the large language model to generate the code.

7. The system of Claim 1, wherein the computing server device is further configured to create the data structure of headers by: reading the library of software code components; identifying the headers within the software code components; and writing identified headers to the data structure.

8. The system of Claim 1, wherein the computing server device is further configured to: receive an indication of a newly added software code component to the library; identify at least one header within the newly added software code component; and add the at least one header to the data structure.

9. The system of Claim 1, wherein the computing server device is configured to generate the code by combining the second set of the software code components together using defined linkages, calls, and references that are provided within the second set of the software code components.

10. The system of Claim 1, wherein the computing server device is configured to use the task query and the data structure to select headers that semantically match the task query by: performing a first semantic match of the task query to headers of software modules of the software code components; performing a second semantic match of the task query to headers of software functions of the software code components that are contained within the closest matching headers of the software modules; performing a third semantic match of the task query to headers of software classes of the software code components that are contained within the closest matching headers of the software functions; and selecting the first set of the software code components that correspond to the closest matching software classes.

11. A memory device including: a library of software code components, each of the software code components including executable codes and one or more docstrings, each docstring including a header and a body; and a data structure including headers of the one or more docstrings for the software code components included within the library, wherein each of the software code components is configured to be modular, interoperable, and decoupled to enable a large language model to generate codes using the software code components.

12. The memory device of Claim 11, wherein the software code components comprise software modules, software functions, software classes, and software submodules.

13. The memory device of Claim 11, wherein the header includes one or more lines of a respective docstring that provides a general description of functionality of the respective software code component.

14. The memory device of Claim 11, wherein the body includes a plurality of lines of a respective docstring that detail arguments, types, and intended functionality of the respective software code component.

15. The memory device of Claim 11, wherein each of the software code components is configured to contain less than 150 to 100 lines of code.

16. The memory device of Claim 11, wherein the software code components are programmed in at least one of Python, C#, C++, or JavaScript.

17. A system including: an interface communicatively coupled to a user device via a network; a memory device storing: a library of software code components, each of the software code components including executable codes and one or more docstrings, each docstring including a header and a body; and a computing server device communicatively coupled to the memory device and the interface, the computing server device including a large language model that is trained to generate codes, which when executed by the computing server device, causes the computing server device to: receive a task query from the user device via the interface, the task query specifying a task or code to be generated, use the task query to select headers that semantically match the task query, select a subset of the software code components by identifying the software code components that correspond to the selected headers, create a prompt by combining the docstrings of subset of the software code components with the task query, generate the code based on the prompt, and provide the code generated to the user device.

18. The system of Claim 17, wherein the computing server device is further configured to: receive an indication of a newly added software code component to the library; identify at least one header within the newly added software code component; and add the at least one header to the software code components.

19. The system of Claim 17, wherein the header includes one or more lines of a respective docstring that provides a general description of functionality of the respective software code component, the body includes a plurality of lines of a respective docstring that detail arguments, types, and intended functionality of the respective software code component.

20. The system of Claim 17, wherein each of the software code components is configured to be modular, interoperable, and decoupled to enable the large language model to generate the code.

Images