A construction method and system of a production available code interpretation large model

Abstract

The application provides a construction method and system of a code interpretation large model for production, which comprises the following steps: selecting a Base model for training the code interpretation large model; selecting a scoring tool for evaluating the final effect of the code interpretation large model from the business perspective; constructing a code interpretation knowledge graph based on GraphRAG; and constructing the code interpretation large model based on the post-training method of SFT fine-tuning. The method can help developers better master the logic of the source code from the technical perspective, and help business personnel understand the entire end-to-end logic from the transaction dimension, thereby providing underlying capabilities for scenarios such as enabling code interpretation assistant AI Agent products, and enabling the two-way synchronization of R&D process platform assets and code assets.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method for constructing a large, production-ready code interpretation model. Background Technology

[0002] With the rapid development of artificial intelligence technology, the field of natural language processing has achieved remarkable results. Various large-scale models trained on natural language text, such as GPT and BERT, have emerged, performing excellently in applications such as text generation, question answering systems, and machine translation, greatly promoting the development and widespread application of natural language processing technology. However, in the field of code intelligence, especially in code interpretation, there are relatively few large-scale models specifically designed for code interpretation.

[0003] Traditional large-scale models mostly focus on scenarios such as semantic recognition and intelligent question answering, lacking systematic support for code interpretation. Therefore, how to build large-scale models for code interpretation has become an urgent technical challenge. Summary of the Invention

[0004] To address the aforementioned problems, the purpose of this invention is to provide a method for constructing a large, production-ready code interpretation model.

[0005] This invention provides a method for constructing a large-scale code interpretation model that can be produced, comprising: selecting a base model for training the large-scale code interpretation model; selecting a scoring tool to evaluate the final effect of the large-scale code interpretation model from a business perspective; constructing a code interpretation knowledge graph based on GraphRAG; and constructing the large-scale code interpretation model based on the base model using a post-training method with SFT fine-tuning.

[0006] Optionally, based on the aforementioned base model, constructing a large-scale code interpretation model using a post-training approach with SFT fine-tuning includes: using the open-source large-scale model fine-tuning training framework LlamaFactory in conjunction with an instruction-supervised fine-tuning dataset to perform SFT fine-tuning on the selected qwen2-72b-instruct base model, allowing the base model to learn the response methods in the instruction-supervised fine-tuning dataset, i.e., the code interpretation methods and response formats, to obtain an initial version of the large-scale code interpretation model; conducting question-and-answer experiments on the initial version of the large-scale code interpretation model using a test set to identify bad cases and cases that do not meet the expectations of business experts. The system obtains answers from test questions and standard answers from business experts. A preference dataset is constructed using the test questions, bad cases, and standard answers. The initial version of the code interpretation model is fine-tuned using the open-source large-scale model fine-tuning training framework LlamaFactory, combined with the preference dataset. This allows the code interpretation model to learn user preferences, resulting in a DPO-optimized code interpretation model. The DPO-optimized model is then used to conduct question-and-answer experiments on a test set to identify bad cases, construct a preference dataset, and continue DPO optimization. After multiple rounds of DPO optimization, the final version of the code interpretation model is obtained.

[0007] Optionally, building a knowledge graph based on GraphRAG includes: selecting qualified Parquet files from the original directory output by GraphRAG and transferring them to the selected GraphRAG output directory; batch converting all Parquet files from the selected GraphRAG output directory to CSV files; preprocessing the data sources join_texu_units_to_entity_ids.csv and join_texu_units_to_relations_hip_ids.csv, which serve as Edge edges, to adapt the data format to the import of the nebula-importer tool; a Python program calling the nebula-importer tool based on each YAML configuration file to import the CSV data into NebulaGraph; and replacing all placeholders in the NebulaGraph import template file, converting it into a configuration file that the import tool nebula-importer can interpret for use by the nebula-importer tool.

[0008] Optionally, beam search can be used to address the "repeating" problem during code interpretation and large model inference. Configure the hyperparameters as follows: use_beam_search=True, temperature=0, top_p=1, top_k=-1, best_of=5, early_stopping=True.

[0009] Optionally, the code interpretation problem in large-scale model inference can be addressed by using DPO (Duplicate Policies) to penalize repetition. This includes: generalizing to examples where repetition occurs; reproducing examples where repetition also occurs after generalization, thus avoiding directly including the correct answer (chosen) and the repeated answer (reject) of bad case examples into the DPO dataset; constructing a DPO preference dataset where, for generalized examples, chosen is the standard answer and non-repeating output, and rejected is the repetitive output similar to a repeater; this is accomplished by constructing counterexamples with repetition counts raised to powers of 2; and using the LlamaFactory fine-tuning framework combined with the DPO preference dataset to perform DPO on the current code interpretation large-scale model that exhibits the repetition problem, resulting in an optimized code interpretation large-scale model.

[0010] Optionally, the structure of the large model for code interpretation includes: Input data: including source code and XML configuration files; Source code is a standard Java file used to implement business logic, service functions, exception handling, and data interaction; XML configuration files, i.e. metadata models, refer to specific types of XML files that define metadata such as transaction processes, service functions, table structures, and error codes in the project.

[0011] Output data: PlantUML formatted text, a standard PlantUML flowchart syntax description; draw.io structured data, conforming to draw.io XML or JSON standard data formats; manim animation scripts, Python code files, using the manim library for animation generation;

[0012] Internal structure: Preprocessing layer: standardizes semi-structured text, extracts core events, actions, and object relationships, and uses regex-based keyword extraction and structural decomposition; Semantic construction layer: calls the LLM model to generate interpretation results from the preprocessed structured text content; Format mapping layer: maps the output format syntax to the syntax structure required by PlantUML, draw.io, and manim; Output generation layer: finally serializes to the corresponding file format, and performs syntax concatenation and file encapsulation according to the target format.

[0013] The present invention also provides a system for building large, usable code-interpreting models, including a processor and a memory; the memory is used to store program code and transfer the program code to the processor; the processor is used to execute the method according to the instructions in the program code.

[0014] The production-readable code interpretation model construction method of this invention, from a developer's perspective, facilitates a better understanding of the source code logic from a technical standpoint. This primarily involves a micro-level interpretation at the methodological level; reading and interpreting the implementation logic in natural human language is always more convenient and intuitive than simply looking at the source code itself. From a business perspective, it helps business personnel understand the entire end-to-end logic from a transactional perspective. For example, it identifies which modules and methods are involved in a particular transaction, the collaborative relationships between these modules, and how the overall end-to-end process is implemented. Furthermore, it facilitates business personnel understanding the specific logic behind particular business rules. Business personnel may understand the macro-level logic of a rule, but may not understand the fine-grained explanation; in such cases, the code interpretation model helps interpret the fine-grained source code rules.

[0015] The post-training method of the code interpretation large model of this invention has many differences compared with the post-training method of conventional large models. It solves various bad cases encountered in the process and makes it a truly usable code interpretation large model. It provides underlying capabilities for empowering code interpretation assistant AI agent products and enabling bidirectional synchronization of R&D process platform assets and code assets.

[0016] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0017] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0018] Figure 1 This is a schematic diagram of the construction method for interpreting large models for production use according to an embodiment of the present invention;

[0019] Figure 2 The ROUGE-L implementation of this invention is not suitable for evaluating the final performance of large models in code interpretation.

[0020] Figure 3 This is a schematic diagram of the AI ​​scoring tool generating assessment point prompts and scoring prompts according to an embodiment of the present invention;

[0021] Figure 4 This is a schematic diagram of the converted file according to an embodiment of the present invention;

[0022] Figure 5This is a schematic diagram illustrating the process of interpreting the knowledge graph using the GraphRAG construction code in an embodiment of the present invention.

[0023] Figure 6 This is a schematic diagram of the final knowledge graph constructed according to an embodiment of the present invention. Detailed Implementation

[0024] The embodiments of the present invention are described below with reference to the accompanying drawings and technical implementation details. Those skilled in the art should understand that these embodiments are only used to explain the present invention and are not restrictive.

[0025] This invention provides a method for constructing a large, production-ready code interpretation model, such as... Figure 1 As shown, the method for constructing a production-ready large code interpretation model according to an embodiment of the present invention may include: S1, selecting a base model for training the large code interpretation model; this involves selecting evaluation tools for evaluating the base model and related experimental verification.

[0026] S2 involves selecting a scoring tool to evaluate the final performance of the large model from a business perspective. This involves evaluating existing tools on the market and determining their suitability; if unsuitable, a new tool needs to be developed in-house.

[0027] S3, based on GraphRAG, constructs a code interpretation knowledge graph to meet the code interpretation and question-answering needs of small-scale projects. The constructed code interpretation model serves as a question-answering model (i.e., the user inputs business code, and the code interpretation model can interpret the code to generate the corresponding business description). The knowledge graph is used as supplementary context for question-answering, helping the model better understand the semantic connotation and complex relationships of the question through the structured representation of entities and relations, rather than just staying at the keyword matching level. This invention provides a knowledge graph construction project for constructing a knowledge graph for business code projects that require interpretation, utilizing GraphRAG technology.

[0028] S4. Based on the aforementioned base model, a large-scale code interpretation model is constructed using a post-training approach with SFT fine-tuning to meet the code interpretation and question-answering requirements of large-scale projects. During post-training, relevant hyperparameters need to be optimized to improve training efficiency and address the "alignment" issue.

[0029] Large-scale code interpretation models are an emerging field, and there are currently no corresponding evaluation tools available on the market. This invention provides best practices for constructing code knowledge graphs based on GraphRAG to meet the code interpretation needs of small and medium-sized applications, as well as best practices for training production-ready large-scale code interpretation models to meet the code interpretation needs of large-scale applications. This provides significant guidance for the entire ecosystem on how to fully leverage the value of code assets. The following sections provide detailed explanations of each step.

[0030] S1, select the base model used to train the large model for code interpretation.

[0031] Selecting a base model for a large-scale code interpretation model requires addressing the evaluation tool issue first. When choosing a base model for training the large-scale code interpretation model, the following evaluation tools related to coding were tested: established benchmarks include CodeXGLUE, HumanEvalExplain from bigcode-evaluation-harness, and MBPP; while emerging benchmarks include LiveCodeBench from LiveBench. Key conclusions are as follows:

[0032] Conclusion 1: CodeXGLUE is not suitable as an evaluation tool for the base model of code interpretation. a. CodeXGLUE's scoring algorithm is based on the BLEU scoring algorithm. From the algorithm itself, the BLEU scoring algorithm does not fully consider the Abstract Syntax Tree (AS), and the BLEU algorithm significantly overvalues ​​long answers. b. Although the CodeXGLUE JSONL dataset contains Chinese text for source code interpretation, this Chinese text does not represent a complete explanation of the code; it is merely a very simple Javadoc comment at the method header. Therefore, the dataset is unusable in "code interpretation" scenarios.

[0033] Conclusion 2: HumanEvalExplain in bigcode-evaluation-harness is also unsuitable as an evaluation tool for the base model of code interpretation. This is because HumanEvalExplain's evaluation of code interpretation essentially involves penetrating into CodeXGLUE.

[0034] Conclusion 3: MBPP is also unsuitable as an evaluation tool for the Base model of code interpretation. This is because MBPP is specifically designed for Python programming testing and can only be used for Python programming (i.e., it only converts natural language into Python source code, demonstrating programming ability, not interpretation ability). Therefore, MBPP is not suitable as an evaluation tool for projects written in Java.

[0035] Conclusion 4: LiveCodeBench currently only has four capabilities (Code Generation, SelfRepair, Test Output Prediction, and Code Execution), and does not support code interpretation.

[0036] Based on the above factual assessment, it was decided to adopt a manual scoring method by business experts. The specific method is as follows: a set of challenging questions is selected to evaluate the capability gap between the Base models. Specifically, 15 Java code interpretation questions based on e-commerce business logic (such as inventory overselling judgment) and 5 questions on the interpretation of extremely complex core system business logic are mixed together. Various candidate Base models are then given the questions to answer, and the quality is judged manually.

[0037] The criteria for judging the ability of a basic model to interpret Java code are: 1. The interpreted content must include both code and key explanations, especially key code and related explanations, and cannot be just text; 2. The interpretation should be logical, similar to a thought process chain, outlining the steps from first to third; 3. The interpretation must be accurate, not merely a literal translation of the source code. A test prompt needed to be designed, and several candidate large models of medium size (around 70 bytes) were selected as inputs for evaluation. Ultimately, qwen2-72b-instruct was deemed the best performing basic model for interpreting large code models.

[0038] S2 is a scoring tool used to evaluate the final effect of the code interpretation of the large model from a business perspective.

[0039] The following are conventional evaluation methods and conclusions regarding the final performance of large-scale code interpretation models after evaluation: Evaluation Conclusion 1: ROUGE-L is not suitable for evaluating the final performance of large-scale code interpretation models, such as... Figure 2 As shown. From Figure 2 It can be seen that: Weighted_average: Since the questions have no weights and all questions have the same priority, this field is meaningless. It only becomes meaningful if the weight of code within a specific module is increased (e.g., in core applications, deposit and loan code would be weighted higher than in ordinary modules). Geometric_Mean: This is more suitable for calculating the mean of data growing proportionally, so it's not suitable for code interpretation. Harmonic_Mean: This is relatively suitable because it harmonizes differences in rates, scales, difficulties, and abilities. For code interpretation, the difficulty of the questions varies, and the scores also differ; this harmonic mean can be used to calculate the difficulty differences. However, the harmonic mean values ​​in the table are too small; minute differences cannot demonstrate its actual effect. Therefore, it is also unsuitable as an evaluation method for large-scale code interpretation models.

[0040] Evaluation Conclusion 2: The BLEU algorithm is also not suitable for evaluating the final effect of large models when interpreting code.

[0041] First, run a case with a high BLEU score but a 0% accuracy rate. Suppose the standard answer is "deducted by the legal authority," but the code interpretation model interprets the answer as "withdrawal by the legal authority":

[0042] In the standard implementation of BLEU, n-gram (n-gram, i.e., N consecutive words in the text) takes the value 1, 2, 3, or 4.

[0043] If n=1 in an n-gram, i.e., in the form of a unigram, then:

[0044]

[0045] Therefore, the value of P1 (the proportion of n-gram words appearing in the standard answer, where n=1 represents the LLM output) = 5 / 6

[0046] If n=2 for n-gram, i.e., in the form of a Bigram, then:

[0047]

[0048] Therefore, the value of P2 (the proportion of n-gram words appearing in the standard answer, where n=2 represents the LLM output) = 4 / 5

[0049] If n=3 for an n-gram, i.e., in the form of a Trigram, then:

[0050]

[0051] Therefore, the value of P3 (the proportion of n-gram words appearing in the standard answer, where n=3 represents the LLM output) = 3 / 4

[0052] If n=4 in an n-gram, i.e., in the form of a Fourgram, then:

[0053]

[0054] Therefore, the value of P4 (the proportion of n-gram words appearing in the standard answer, n=4 in the LLM output) = 2 / 3; the weighting coefficient WN = 1 / N (N=4) = 0.25.

[0055] Since P1 to P4 are all relatively small values, they will be logarithmized (this is a common way to handle small numbers; in general mathematical calculations, in order to prevent the product of two decimals with an absolute value less than 1 from being too close to 0, the decimals are usually logarithmized).

[0056] The base can be a base of 2, or it can be the natural logarithm e. Here, we use the natural logarithm e as the base. Therefore:

[0057] Sigma(1 / N logP(n)) = 0.25*ln(P1) + 0.25*ln(P2) + 0.25*ln(P3) + 0.25*ln(P4).

[0058] Since the logarithm of a number less than 1 is negative, the above result is negative. Therefore, it will eventually be exponentialized using the exp() function (an exponential function with the natural logarithm e as the base). The exp() function is a common function in mathematics. Its purpose is to transform any negative number into a number in (0,1) while ensuring monotonic increase.

[0059] Exp(Sigma(1 / NlogP(n))=Exp(0.25*ln(P1)+0.25*ln(P2)+0.25*ln(P3)+0.25*ln(P4))

[0060] The BP coefficient in the BLUE algorithm is a penalty factor used to penalize short phrases. The formula for the BP coefficient is:

[0061]

[0062] Where c = candidate (the output of the large model) and r = reference (the standard answer).

[0063] Because the large model outputs "(deduction by legal authority)" with 6 characters, i.e., c = 6, and the standard answer "(deduction by legal authority)" also has 6 characters, i.e., r = 6, therefore c <= r, BP = e(1 - r / c) = e0 = 1, meaning no penalty is imposed.

[0064] Therefore, the final value = BP penalty factor * Exp(sigma(1 / N logP(n)))

[0065] =1*exp(0.25*ln(P1)+0.25*ln(P2)+0.25*ln(P3)+0.25*ln(P4))

[0066] =1*exp(0.25*ln(5 / 6)+0.25*ln(4 / 5)+0.25*ln(3 / 4)+0.25*ln(2 / 3))

[0067] =1*exp((-0.04558)+(-0.05579)+(-0.07192)+(-0.10137))

[0068] =1*exp(-0.27466)=0.75983=75.98%

[0069] Therefore, the score based on the BLEU algorithm is very high, reaching nearly 76% similarity, but the accuracy is 0.

[0070] The control group then ran a case with a very low BLEU score but high accuracy. Suppose the standard answer is "deducted by the legal authority," but the code interpretation model interprets it as "frozen and allocated according to law." It can be seen that although the model's interpretation differs greatly from the standard answer literally, the semantics are similar to how BLEU scores are calculated.

[0071] If n=1 in an n-gram, i.e., in the form of a unigram, then:

[0072]

[0073] Therefore, the value of P1 (the proportion of n-gram words appearing in the standard answer, where n=1 represents the output of the control group) is 2 / 6.

[0074] If n=2 for n-gram, i.e., in the form of a Bigram, then:

[0075]

[0076] Therefore, the value of P2 (the proportion of n-gram words appearing in the standard answer, where n=2 represents the output of the control group) is 0 / 5.

[0077] If n=3 for an n-gram, i.e., in the form of a Trigram, then:

[0078]

[0079] Therefore, the value of P3 (the proportion of n-gram words appearing in the standard answer, where n=3 represents the output of the control group) is 0 / 4.

[0080] If n=4 in an n-gram, i.e., in the form of a Fourgram, then:

[0081]

[0082] Therefore, the value of P4 (the n-gram words that appear in the standard answer, where n=4 represents the proportion of the output of the control group) is 0 / 3.

[0083] Because the control group outputs 6 characters (legally frozen and allocated), i.e., c=6, and the standard answer (legally deducted by the legal authority) also has 6 characters, i.e., r=6. Therefore, c<=r, BP=e(1-r / c)=e0=1, meaning no penalty is imposed.

[0084] Therefore, the final value = BP penalty factor * Exp(sigma)1 / N logP(n))

[0085] =1*exp(0.25*ln(P1)+0.25*ln(P2)+0.25*ln(P3)+0.25*ln(P4))

[0086] =1*exp(0.25*ln(2 / 6)+0.25*ln(0 / 5)+0.25*ln(0 / 4)+0.25*ln(0 / 3))

[0087] = 1*exp((-0.27465)+(negative infinity)+(negative infinity)+(negative infinity))

[0088] =1*exp(-negative infinity)=0=0%

[0089] Therefore, the score based on the BLEU algorithm is 0, but the accuracy rate of the answers is very high.

[0090] Based on the experimental and control groups, it can be demonstrated that the BLEU algorithm is not suitable for evaluating the final performance of large code-reading models. Traditional scoring methods, such as the ROUGE-L algorithm or the BLEU algorithm, cannot solve the problem of correctly scoring post-trained large code-reading models from the perspective of actual performance. Therefore, AI scoring tools need to be considered.

[0091] The first issue to address is the legitimacy of the AI ​​scoring tool, i.e., how to prove its trustworthiness. One method is to have it evaluate the interpretation of the example code included in the built-in prompt, checking if it achieves a perfect score of 100. Two problems were discovered: first, directly evaluating the interpretation of the example code in the built-in prompt using AI scoring only yielded 25 points instead of 100; second, the AI ​​scoring logic required answers to demonstrate detail to receive points, otherwise, zero. While the base model's generalization ability was weak, its detailed answers resulted in higher scores; the subsequently trained model, with significantly enhanced generalization ability, lost many details, leading to severe point deductions. Thus, the later-trained code interpretation model actually performed worse than the base model.

[0092] Observation revealed certain flaws in the AI ​​scoring mechanism. For example, the standard answer after code interpretation only highlighted point A, but if the large model included irrelevant points B, C, D, E, F, G, and H, it could still score points on the question. This indicates that the direct AI scoring method included irrelevant content in an attempt to achieve a higher score. Business users, as the actual users, prefer concise and accurate answers, not lengthy responses containing many irrelevant details. Therefore, they hope to introduce a "negative scoring mechanism" to penalize excessively divergent answers aimed at obtaining high scores.

[0093] The negative scoring mechanism has encountered difficulties in implementation. This is because computers are typically binary (True or False) models, and they are not good at handling multi-state models (positive scores, 0 scores, and negative scores). Furthermore, the magnitude of the Y-intercept of the numerical values, such as 3, 4, or -5, cannot be described in a computer using a Turing-complete algorithm.

[0094] This embodiment ultimately adopts an AI-based assessment point scoring method. This involves the AI ​​breaking down assessment points and evaluating whether the current answer scores a point on that point (1 point for a score, 0 points for a score not received). The considerations for this approach are: a. Any penalty mechanism can be modeled as a combination of assessment points, with points not scoring for specific scenarios. b. For a large base model without post-training, to penalize its "redundancy bias," assessment points can be set targeting this bias. c. Rather than assigning specific numerical scores, AI excels at determining whether a particular assessment point is hit or missed, and explains from the AI's perspective why a point is hit or missed. The AI ​​scoring tool is continuously iterated and optimized through evaluation of the AI's explanations by business experts.

[0095] Ultimately, an AI scoring tool was designed that meets the evaluation requirements of large-scale code interpretation models after post-training. This AI assessment point scoring tool is a powerful supplement to the lack of large-scale code interpretation model evaluation tools on the market, and it is also usable in actual production. This also provides a good reference for how the ecosystem can fully evaluate the effectiveness of code interpretation.

[0096] The AI ​​scoring tool generates assessment point prompts and scoring prompts, as shown in the example below. Figure 3 As shown. The working principle is as follows:

[0097] 1) The exam questions are set by business experts, consisting of questions and standard answers.

[0098] 2) Use large AI models (such as GPT-4O) to generate several assessment points for this question based on the standard answer.

[0099] 3) Manually correct any unreasonable assessment points (because the assessment points generated by the large model sometimes do not accurately describe the actual business needs).

[0100] 4) By using the code interpretation model to run reasoning and answer questions from the exam set, the code interpretation model can be obtained to answer the question.

[0101] 5) Based on the questions and assessment points, the AI ​​scores the code interpretation model's answers (e.g., GPT-4O) to evaluate whether the current answer scores points on this assessment point (1 point if it scores points, 0 points if it does not).

[0102] 6) The ability of each fine-tuned version of the code interpretation model can be evaluated and inferred from its score on this test set.

[0103] During the AI ​​scoring process, the scoring criteria are traceable throughout, and the system outputs a thought process chain, explaining the basis and reasons for scoring and deducting points. From the AI's perspective, it explains why a particular assessment point received a score or no score. The AI ​​scoring tool is continuously iterated and optimized by having business experts assist in evaluating the rationality of the AI ​​scoring explanations.

[0104] The lifecycle of an AI scoring tool is as follows: 1) Import questions and standard answers; 2) Generate assessment points; 3) Visually review and edit assessment points and standard answers; 4) Verify the correctness and rigor of assessment points (i.e., whether assessment points can be scored under the standard answer, and whether counterexamples will result in lost points); 5) Optimize assessment points; 6) Run reasoning on the large model to be evaluated through the questions in the exam set to obtain the model's answers and score the answers with AI based on the questions and assessment points; 7) Visually filter out questions and assessment points that do not meet expectations; 8) Repeat step 3) or adopt the scores.

[0105] S3, based on GraphRAG, builds code to interpret knowledge graphs.

[0106] Because code interpretation scenarios involve multi-hop reasoning, traditional RAG solutions are not well-suited for this purpose. Therefore, this embodiment uses Microsoft's GraphRAG solution. GraphRAG essentially uses a knowledge graph stored in a graph database for indexing, construction, and retrieval, rather than relying on knowledge vectors stored in a vector library, as is the case with traditional RAG. The graph database serves as the storage medium for the knowledge graph. NebulaGraph was chosen over Neo4j primarily because the community edition of Neo4j does not support clustered deployment. The lower-cost LlamaIndex GraphRAG solution was not used because it would result in a large number of discrete entities (classes, interfaces, methods, and fields are all entities) lacking interconnected relationships.

[0107] Ultimately, Microsoft's GraphRAG was chosen. GraphRAG itself doesn't offer direct integration with Nebulagraph, and its operation is independent of Nebulagraph; Nebulagraph only serves as a bypass (for knowledge graph visualization). Considering that GraphRAG's main output is Parquet files, which are columnar stored and can be converted to CSV files, and CSV files can be imported into Nebulagraph using the Nebula-importer tool, the overall approach to importing knowledge graphs into the graph database is: read the artifact directory of GraphRAG, convert these Parquet files to CSV files, and then import them into the Nebulagraph graph database using the Nebulagraph import tool. Several other considerations exist in practical applications.

[0108] Consideration 1: Not all files in the Microsoft GraphRAG artifact directory need to be converted into data files. Taking a complete output from a single Microsoft GraphRAG execution as an example, all graphml files are unnecessary; these are only for graphical visualization and do not contain data. Furthermore, some Parquet files should be excluded, such as create_base_entity_grap-h.Parquet, which contains only one graphml file, as do create_base_extracted_entities.Parquet and create_summarized_entities.Parquet. Therefore, a processing step is needed to select the required Parquet files from the Microsoft GraphRAG artifact directory.

[0109] Consideration Point 2: Not all CSV files can be directly imported into NebulaGraph. CSV files generated by Microsoft GraphRAG for providing edge data do not strictly adhere to the fundamental principle that "each row represents a relation." For example, `join_text_units_to_entity_ids.Parquet`, after being converted to its corresponding `join_text_units_to_entity_ids.csv` file, would look like this: Figure 4 As shown.

[0110] Focus Figure 4Lines 2 through 11 show that there are many entity_ids corresponding to text_unit_ids starting with 4a1. These are enclosed in square brackets, but these brackets are not a list because the values ​​are not separated by commas. Furthermore, some values ​​are separated by whitespace, while others are separated by newline characters (\n). Therefore, this type of file cannot be directly imported into NebulaGraph. Preprocessing is required. Thus, the two files used to establish Edge relationships (join_text_units_to_entity_ids and join_text_units_to_relationship_ids) each require preprocessing. The value of preprocessing is to transform CSV files that do not meet NebulaGraph's import requirements into CSV files that do, ensuring that each row in the transformed CSV file corresponds to a relationship.

[0111] Consideration Point 3: Clarify the common and different parts of the various configuration files that nebula-importer depends on. Nebula-importer imports CSV files, always requiring a corresponding YAML configuration file. Within this file, corresponding tags or edges must be pre-created using `manager.hooks.before.statements`, and the `sources` section must specify which column in the target CSV file each field originates from. For example, in `import_create_final_documents.yaml`, it requires the `CREATE TAG` function to be pre-created in the hook on line 22.<TAG_NAME> The statements create the corresponding TAG (node) and its various attribute fields. Line 30 specifies the CSV file to be imported via `sources.path` and provides its path. Lines 35 to 55 define which column of the CSV file the current TAG's ID comes from (index=0 indicates the first column), and which column of the CSV file each attribute field comes from (index=N).

[0112] Any CSV file corresponds to different TAGs (node ​​data in NebulaGraph) or EDGEs (edge ​​data in NebulaGraph), and the corresponding fields are also different.

[0113] The various configuration files also share commonalities, such as connecting to the same data source, meaning the address, user, password, and spaceName of `nebula_graph` are all identical. Therefore, a YAML configuration template is used to generate the corresponding YAML file. This involves pre-defining a set of templates with placeholders, containing both common and custom substitution characters. Common substitution characters include `${NEBULAGRAPH_ADDR}`, `${NEBULAGRAPH_USER}`, `${NEBULAGRAPH_PASSWORD}`, and `${NEBULAGRAPH_SPACE_NAM-E}`; custom substitution characters specify the path to each CSV data source file for each configuration file. Through template variable substitution, this template file is converted into a corresponding YAML file that can be correctly parsed by the `nebula-import` tool.

[0114] Consideration 4: The import process needs to be automated programmatically, rather than manually executed via command line using nebula-importer. The official example uses a pre-compiled nebula-import tool and commands passing a configuration file to import CSV data, but this is extremely time-consuming and laborious. This is mainly due to the 11 distinct CSV files, requiring 11 different YAML configuration files and 11 separate command executions. Furthermore, if any execution fails, all the relevant configuration information in the YAML configuration files needs to be modified again.

[0115] The solution is to use Python to call the bin tool of nebula-importer. This can be done by calling the function subprocess.run([nebula_importer_path,"--config",config_root+" / i-mport_create_base_text_units.yaml"]), which is used to execute the command corresponding to "nebula-importer --config a certain yaml configuration file".

[0116] Taking the above considerations into account, the final process of building code to interpret the knowledge graph based on GraphRAG is as follows:

[0117] 1. Slice Up

[0118] The input corpus, i.e., the original project's corpus file, is read by GraphRAG and segmented into a series of TextUnits. These TextUnits serve as analyzable units in subsequent processing and provide fine-grained references in the output. This step is likely for better management and retrieval of text data.

[0119] 2. Entity and Relationship Extraction

[0120] All entities, their relationships, and key claims are extracted from TextUnits using a large language model (LLM). This facilitates the construction of a knowledge graph, where entities, relationships, and claims form the nodes and edges of the graph.

[0121] 3. Graph Clustering

[0122] The Leiden algorithm is used to perform hierarchical clustering of the graph. In this process, each circle represents an entity (such as a person, place, or organization), the size of the circle reflects the degree of the entity (i.e., the number of edges connected to it), and the color represents the community it belongs to. This step helps to identify groups of entities with similar attributes or close connections.

[0123] 4. Community Summarization

[0124] The system generates summaries of each community and its members from the bottom up. This means that the system creates a summary for each detected community, which helps in understanding the overall content and structure of the dataset.

[0125] The overall process of building and interpreting knowledge graphs based on GraphRAG is as follows: Figure 5 As shown, it includes:

[0126] S3-1: Select the required Parquet files from the original directory of Microsoft GraphRAG output to the processing directory, which is the selected GraphRAG output directory;

[0127] S3-2, batch convert all Parquet files to CSV files from the selected GraphRAG output directory;

[0128] S3-3, preprocess the join_text_units_to_entity_ids.csv file, which serves as the data source for the Edge edges. This file cannot be directly imported into NebulaGraph; the list in the second column must be converted into single values.

[0129] S3-4, Preprocess the join_text_units_to_relationship_ids.csv file. This file cannot be directly imported into NebulaGraph. The list in the second column must be converted to single values ​​to make the data format compatible with the nebula-importer tool.

[0130] S3-5, the Python program calls the nebula-importer tool based on each YAML configuration file to import CSV data into NebulaGraph; it replaces all placeholders in the nebulagraph import template file, converting it into a configuration file that nebulagraph_importer can interpret, so that it can be used by the nebula-importer tool (nebula import tool);

[0131] S3-6, based on the configuration file, calls the nebula_importer tool one by one to correctly import the corresponding CSV data files into NebulaGraph, and the final generated knowledge graph is as follows. Figure 6 As shown.

[0132] When the mouse hovers over a vertex, detailed information about the nodes involved in that relationship can be seen; when the mouse hovers over an edge, detailed information about that edge can also be displayed.

[0133] The main problem encountered when analyzing source code and building a knowledge graph using Microsoft GraphRAG is the extremely high token overhead required for the complete construction. For large projects, this can involve tens or even hundreds of millions of tokens. An alternative solution is to use GraphRAG's NLTK to extract entity-relation relationships from the source code; this is a Python package used for analyzing human language.

[0134] NLTK has three main drawbacks: First, the extraction process frequently fails, especially when the corpus contains multiple languages. Second, if NLTK is used for entity-relation extraction, it loses the rich supplementary information in the entity knowledge's description field, simply copying the entity name and placing it in the description field. Third, while NLTK significantly reduces token consumption in the entity-relation extraction stage, the time spent on "creating covariates" and "creating community reports" is much longer than that of large-scale model-based processing, thus it is not advantageous in terms of overall time. Therefore, building a knowledge graph based on Microsoft GraphRAG is only suitable for small to medium-sized projects, but it is still a feasible approach.

[0135] S4, based on the aforementioned base model, employs a post-training approach using SFT fine-tuning to construct a large-scale code interpretation model. This embodiment primarily utilizes the LlamaFactory training framework and combines it with a high-quality dataset to fine-tune the large-scale code interpretation model. Specifically, it includes:

[0136] S1-1 uses the open-source large model fine-tuning training framework LlamaFactory combined with a high-quality instruction-supervised fine-tuning dataset (which can be pre-collected) to perform SFT fine-tuning on the selected qwen2-72b-instruct base model. This allows the base model to learn the response methods in the instruction-supervised fine-tuning dataset, i.e. the way the code is interpreted and the response format, to obtain the initial version of the large code interpretation model.

[0137] S1-2. Then, we will conduct some code interpretation question-and-answer experiments on the initial version of the code interpretation model using a test set (exam questions) to identify bad cases and answers that do not meet the expectations of business experts. We will then ask business experts to provide the standard answers corresponding to the exam questions, and then construct a preference dataset using the exam questions, bad cases, and standard answers.

[0138] S1-3 uses the open-source large model fine-tuning training framework LlamaFactory combined with a high-quality preference dataset to perform DPO on the initial version of the code interpretation large model, allowing the model to learn user preferences and obtain the code interpretation large model after DPO.

[0139] S1-4, then conduct question-and-answer experiments on code interpretation using a test set (exam questions) to identify bad cases and construct a preference dataset. Continue with DPO (Data Point Objective) and after multiple rounds of DPO optimization, the final version of the large code interpretation model is obtained.

[0140] There are three types of bad cases that may be encountered during the fine-tuning process. The first type of bad case is when the LLM's answer contains heart-like emojis or marketing phrases. The second type of bad case is when the LLM's answer loses its "topic relevance," meaning the content is completely unrelated to the current topic. The third type of bad case is when the LLM's answer simply copies the question asked.

[0141] The essence of these three categories of problems is that "alignment" is not done well. This is because the chosen base model is the Chat model. The biggest characteristic of the Chat model is that text is represented as a series of messages, each with a role and content. The role can take three values: user, assistant, and system. The chat model needs to accept a chat template, system prompt, and user input, then integrate them to generate the rendered_chat, which is necessary for correct content generation. The chat_template contains special markers, such as eos_token as <|im_end|>, pad_token as <|endoftext|>, and additional_special_tokens as <|im_start|> and <|im_end|>.

[0142] These bad cases directly send the user's message content to the chat model without rendering it as `rendered_chat` as required, leading to unpredictable errors. The following script can be used to resolve these bad cases:

[0143]

[0144] After resolving the bad cases, fine-tuning continued. We first tried LoRa, then the quantization technique QLora, but encountered slow convergence. Therefore, we adopted the Pissa approach, which directly performs singular value decomposition on the weight matrix W, selecting the first r largest singular values ​​and their corresponding singular vectors to form the principal component matrix W_pri, and the remaining values ​​to form the residual matrix W_res. During training, W_pri is updated while the residual matrix W_res is kept frozen. Because the principal component matrix is ​​updated directly, the convergence speed is faster.

[0145] Another breakthrough in the fine-tuning code analysis of the large model is the use of the `warmup_stable_decay` learning rate scheduler instead of the traditional cosine scheduler. A key issue with the cosine scheduler is its poor performance during "retraining continuation"; it requires the cosine decay period to be consistent with the number of steps to converge to a local optimum. For fine-tuning, to prevent gradient explosion, a large initial learning rate is set, requiring a large number of steps to converge to a local optimum. However, with the `warmup_stable_decay` learning rate scheduler, better convergence can be achieved with fewer steps. This scheduler is implemented by first performing a fast warmup, then using a fixed learning rate for a period, and finally rapidly decaying to a smaller learning rate. During fine-tuning, a saddle point problem was encountered, where the gradient is 0 but not a maximum or minimum. The solution to the saddle point problem is to increase the learning rate. Since the AdamW optimizer is used in the fine-tuning code analysis of the large model, the learning rate and batch size have a square root scaling relationship. Therefore, the batch size also needs to be increased. The effect was optimized by using multiple experimental control groups. The best practice is to increase the initial batch size by 4 times and the initial learning rate by 2 times to quickly overcome the saddle point.

[0146] In an optional embodiment of the present invention, the problem of "repeating the same thing" during code interpretation and large model inference is solved by beam search. That is, the hyperparameters are configured as follows: use_beam_search=True, temperature=0, top_p=1, top_k=-1, best_of=5, early_stopping=True.

[0147] When using code to interpret a large model, I encountered a "repetition problem." The model continuously outputs data in a streaming manner until it matches a `max_token`. There are two solutions to this problem. One is Pseudo-repetition Penalization Training, which constructs repetitive pseudo-data and designs a repetition penalty term during the training phase to suppress the large model from generating repetitive sentences. This solution comes from the paper: https: / / arxiv.org / pdf / 2206.02369, titled "Learning to break the Loop: Analyzing and Mitigating Repetitons for Netural Text Generation". The other solution uses beam search, an improvement on greedy decoding. It involves configuring the hyperparameters `use_beam_search=True`, `temperature=0`, `top_p=1`, `top_k=-1`, `best_of=5`, and `early_stopping=True`.

[0148] For beam search, the most crucial parameter is `early_stopping`, which controls the termination condition. If `early_stopping` is set to `True`, the search stops when the `best_of` number of candidate results is reached. If `early_stopping` is set to `False`, based on the heuristic algorithm, it stops only when the true optimal solution is found (i.e., no better candidate can be found). If `early_stopping` is set to `Never`, based on the canonical beamsearch algorithm, it stops only when no better candidate can be found. Therefore, as can be seen from the parameter explanation, only setting `early_stopping` to `True` ensures rapid termination. Otherwise, whether it is `False` or `Never`, it will seek the true optimal solution, potentially leading to an infinite number of possible outputs.

[0149] In an optional embodiment of the present invention, the problem of repetition during code interpretation and large model inference is solved by using DPO (Duplicate Point Objective) to penalize repetition. The specific process is as follows:

[0150] 1. For the example of a repeating machine, we first generalize this example.

[0151] 2. Reproducing the generalized examples also resulted in repetitions. This was done to avoid directly including the chosen (correct answer) and rejected (repeated answer) bad case examples into the dpo dataset, as this makes the generalization more convincing.

[0152] 3. Construct a DPO preference dataset. For generalized examples, choose the standard answer with unique outputs, and reject the repeated outputs (like a repeating machine). This is done by constructing negative examples with a power of 2 repetition count. That is, the negative examples in the first group of rejected examples are repeated 2 times; the negative examples in the second group are repeated 4 times; the negative examples in the third group are repeated 8 times; and the negative examples in the fourth group are repeated 16 times.

[0153] 4. Using the LlamaFactory fine-tuning framework combined with the DPO preference dataset, we performed DPO on the current code interpretation model that would encounter the repeater problem, resulting in an optimized code interpretation model.

[0154] Since a repeater essentially outputs repetitive data, a penalty for repeated output can be constructed using Data Point Objectives (DPO). The DPO dataset can be constructed such that `chosen` selects non-repeating outputs, while `rejected` selects repetitive outputs similar to those found in a repeater. This can effectively solve the repeater problem.

[0155] The difficulty of this solution lies in constructing rejected counterexamples, because the repeater may repeat multiple times, with no limit on the number of repetitions. It's impossible to represent repeated counterexamples using regular expressions because the DPO's modification of the large model's logits is executed relatively early, making expansion difficult. Therefore, the solution is to construct counterexamples with repetitions raised to powers of 2. That is, the first group of rejected counterexamples repeats 2 times; the second group repeats 4 times; the third group repeats 8 times; and the fourth group repeats 16 times. Using this DPO approach, the repeater problem is ultimately solved. The classic repeater problem, i.e., streaming output, is encountered in large model inference during code interpretation. This invention provides two solutions: beamsearch and DPO-penalized repetition, which fundamentally solve the repeater problem in large model inference during code interpretation and offer valuable insights for solving this classic industry challenge.

[0156] Based on the code analysis and large model verification after fine-tuning, an example of a repeating machine was found to be absent. Therefore, the repeating machine problem can be solved using DPO (Discriminating Points-Based Policies). The constructed DPO preference dataset uses the negative example from the third group of rejected samples repeated 8 times as an example.

[0157] The structure of the large model in the code interpretation of this invention embodiment can be as follows:

[0158] I. Input Data

[0159] 1. Source code (Java source code file)

[0160] A standard `.java` file refers to a standard Java file within a system used to implement business logic, service functions, exception handling, and data interaction. Its characteristics include: a) Functional objects, containing definitions of classes, interfaces, methods, and fields; b) Structural features, including a clear package structure, comments, method call chains, and exception handling logic; c) Target content, extracting core business processes such as transaction entry points (e.g., Controller classes), service orchestration (Service layer), data operations (DAO layer), and exception handling (Try-Catch structure).

[0161] 2. XML configuration file (metadata model)

[0162] This refers to a specific type of `.xml` file* that defines metadata such as transaction processes, service functions, table structures, and error codes within a project. It is not a generic XML file and mainly includes the following subcategories, each with explicit business semantics:

[0163] a. The FlowTrans definition file `flowtrans.xml` defines the online transaction interface and describes the correspondence between transaction codes and processing logic.

[0164] b. The service function definition file `apsServiceType.xml` defines reusable service function modules.

[0165] c. The service implementation definition file `apsServiceImpl.xml` defines the specific service invocation implementation details (class method binding).

[0166] d. The table structure definition file `tables.xml` defines the database table structure, fields, primary keys, and other information.

[0167] e. The error code definition file `error.xml` defines the mapping relationship between the error codes returned by the system and the error messages.

[0168] f. The data dictionary definition files `d_schema.xml`, `u_schema.xml`, and `e_schema.xml` define data items, basic types, and enumeration types.

[0169] g. The composite type definition file `c_schema.xml` defines a composite data type consisting of multiple data items.

[0170] h. The batch transaction definition file `batch_tran.xml` defines the business process for batch transaction processing.

[0171] i. File Batch Transaction Definition: The file `file_batch_tran.xml` defines batch transaction processing based on file input and output.

[0172] j. Define complex SQL statements and their mapping methods using a custom SQL definition file `nsql.xml`.

[0173] II. Output Data

[0174] 1. PlantUML format text: Standard PlantUML flowchart syntax description.

[0175] 2. draw.io structured data: Data format conforming to draw.io XML or JSON standards.

[0176] 3. manim animation script: Python code file that uses the manim library to generate animations.

[0177] III. Internal Structure

[0178] 1. Preprocessing layer: Standardize semi-structured text, extract core events, actions, and object relationships, and use regular expressions (regex) for keyword extraction and structural decomposition.

[0179] 2. Semantic Construction Layer: This layer uses the LLM model to generate interpretation results from the preprocessed structured text content. Below is a prompt generated by calling the LLM model:

[0180]

[0181]

[0182] 3. Format Mapping Layer: Based on the output format syntax, it maps to the syntax structure required by PlantUML, draw.io, and manim; below is a prompt design template for PlantUML syntax:

[0183]

[0184]

[0185] 4. Output generation layer: Finally serialize it into the corresponding file format. According to the target format, perform syntax splicing and file encapsulation, such as generating puml files, drawio xml, and manim scripts.

[0186] Code interpretation calls the large language model prompt:

[0187] You are a highly skilled Java developer with rich experience in banking and financial operations. Your purpose is to help users understand Java business code containing complex logic. Your task is to interpret the code based on the code provided by the user and summarize the code interpretation results into business rule entries that business personnel can understand, including the functions, purposes, control flows, etc. of the business.

[0188] <Specific requirements>

[0189] When describing business rules, the following conventions should be followed:

[0190] 1. The description of business rules should be structured and presented in the form of numbered lists. Main business rules are numbered with numbers, and sub-rules are numbered in the form of numbers + dots + numbers.

[0191] 2. throw class.method.EXXXX000() is identified as: "xxx error message description".

[0192] 3. For regular assignments xxx.set, data conversions CommUtil.copyProperties, and object initializations newxxxx() / SysUtil.getInstance(xxx), no interpretation is required.

[0193] 4. The description of business rules should be concise and to the point, avoiding repetition and verbosity.

[0194] 5. Each business rule description is an independent unit and should not contain the content of other rules.

[0195] 6. Use general and neutral terms, and avoid using English abbreviations in the code.

[0196] 7. It should accurately reflect the business purpose implemented by the code and not speculate or add content that is not in the code.

[0197] 8. No usage that is not present in the business rule description requirements is allowed.

[0198] < / Specific requirements>

[0199]

[0200] Please generate the corresponding business rules according to the following task code and the implementation of the method body associated with the task code:

[0201] Note

[0202] 1. The implementation of the method body associated with the task code represents the specific implementation part inside some method calls in the task code.

[0203] 2. The task code + the implementation of the method body associated with the task code represent the complete code implementation of a functional point, and the core is to summarize and describe the business rules of this function.

[0204] <Task Code>

[0205] [Here is the specific task code]

[0206] < / Task Code>

[0207] <Implementation of the Method Body Associated with the Task Code>

[0208] [Here is the specific implementation of the method body associated with the task code]

[0209] < / Implementation of the Method Body Associated with the Task Code>

[0210] Example of the output result of the code interpretation by calling the large language model:

[0211] This method is mainly used for the intermediate bookkeeping processing of foreign exchange trading. The business rules are as follows:

[0212] 1. Call the intermediate bookkeeping service for foreign exchange trading

[0213] 1.1 Call the general bookkeeping processing for foreign exchange trading

[0214] 2. Execute the general bookkeeping processing for foreign exchange trading

[0215] 2.1 Verify the buying and selling currency

[0216] 2.1.1 If the buying currency is the same as the selling currency, return empty

[0217] 2.2 Determine the foreign exchange trading type

[0218] 2.2.1 If the buying currency is the local currency, set it as customer foreign exchange sale

[0219] 2.2.2 If the selling currency is the local currency, set it as customer foreign exchange settlement

[0220] 2.2.3 If both the buyer and the seller are foreign currencies, set it as customer foreign exchange arbitrage

[0221] 2.3 Set the relevant information for foreign exchange trading

[0222] 2.3.1 Copy the input parameters to the accounting input object, including information such as the source of funds, destination of funds, buying account, and selling account. 3. Execute the main foreign exchange accounting process.

[0223] 3.1 Calculate the recorded amount

[0224] 3.1.1 Calling the service to calculate foreign exchange trading amounts

[0225] 3.1.2 If the calculation fails, the error message "Failed to calculate foreign exchange trading amount" will be displayed.

[0226] 3.1.3 Verify that the calculated result matches the input amount; if they do not match, report an error.

[0227] 3.2 Obtaining the accounting account

[0228] 3.2.1 Obtain the accounting account based on the foreign exchange transaction type, the currency purchased, and the currency sold.

[0229] 3.2.2 If retrieval fails, the error message "Failed to retrieve accounting account" will be displayed.

[0230] 3.3 Recording foreign exchange transactions

[0231] 3.3.1 Credit the buyer's foreign exchange trading account

[0232] 3.3.2 Debit the seller's foreign exchange trading account

[0233] 3.4 Constructing Output Information

[0234] 3.4.1 Set the purchase currency and amount

[0235] 3.4.2 Set the currency and amount to sell

[0236] 3.4.3 Set exchange rate related information

[0237] 4. Processing the acquisition of local currency

[0238] 4.1 Obtain the base currency configured in the legal entity parameter table

[0239] 4.1.1 If the legal entity parameter table does not exist, an error will be reported.

[0240] 4.1.2 If the base currency is not configured, an error will occur.

[0241] 4.2 Returning the base currency code

[0242] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for constructing a large, production-ready code-interpreting model, characterized in that, The method includes: Select a base model for training the large model that interprets the code; Select a scoring tool that evaluates the final effect of the code interpretation of the large model from a business perspective; This involves building a knowledge graph based on GraphRAG, including: selecting suitable Parquet files from the original GraphRAG output directory and transferring them to the selected GraphRAG output directory; batch converting all Parquet files from the selected GraphRAG output directory to CSV files; preprocessing the data sources join_texu_units_to_entity_ids.csv and join_texu_units_to_relations_hip_ids.csv as Edge edges to adapt the data format to the nebula-importer tool; a Python program calling the nebula-importer tool based on each YAML configuration file to import the CSV data into NebulaGraph; and replacing all placeholders in the NebulaGraph import template file to convert it into a configuration file that the nebula-importer tool can interpret for use by the nebula-importer tool. Based on the aforementioned base model, a post-training approach using SFT fine-tuning is employed to construct a large-scale code interpretation model. This includes: using the open-source large-scale model fine-tuning training framework LlamaFactory in conjunction with an instruction-supervised fine-tuning dataset to perform SFT fine-tuning on the selected qwen2-72b-instruct base model. This allows the base model to learn the response methods from the instruction-supervised fine-tuning dataset, i.e., the code interpretation methods and response formats, resulting in an initial version of the large-scale code interpretation model. The initial version of the large-scale code interpretation model is then used to conduct question-and-answer experiments on a test set to identify bad cases and cases that do not meet the expectations of business experts. The process involves answering questions and obtaining standard answers from business experts for each question. A preference dataset is constructed using the questions, bad cases, and standard answers. The initial version of the code interpretation model is then fine-tuned using the open-source large-scale model fine-tuning training framework LlamaFactory, combined with the preference dataset. This allows the code interpretation model to learn user preferences, resulting in a DPO-optimized code interpretation model. The DPO-optimized model is then used to conduct question-and-answer experiments on a test set to identify bad cases and construct a preference dataset. Further DPO optimization is performed, and after multiple rounds of DPO optimization, the final version of the code interpretation model is obtained. The DPO penalty for repetition addresses the "repeater problem" in code interpretation of large model inference, including: The code interpretation model is generalized to address examples of repeated code snippets. Since repeated code snippets also occur in the generalized examples, the correct answers (chosen) and rejected answers (rejected) of the bad cases with repeated code snippets are not directly included in the DPO dataset. A DPO preference dataset is constructed, where the standard answer (non-repeating output) is selected as the chosen answer and the repeated output (rejected) is selected as the rejected answer. This is achieved by constructing counterexamples with a repetition count that is a power of 2. The LlamaFactory fine-tuning framework, combined with the DPO preference dataset, is used to perform DPO on the current code interpretation model that exhibits the repeated code snippet problem, resulting in an optimized code interpretation model.

2. The method according to claim 1, characterized in that, The beam search method is used to solve the "repeating machine" problem when interpreting code for large model inference.

3. The method according to claim 2, characterized in that, Configure the following hyperparameters: use_beam_search=True, temperature coefficient=0, kernel sampling threshold=top_p=1, candidate set size=-1, candidate sequence number=5, and early termination=True.

4. The method according to any one of claims 1-3, characterized in that, The code analysis of the large model's structure includes: Input data includes source code and XML configuration files; source code is a standard Java file used to implement business logic, service functions, exception handling, and data interaction; XML configuration files, or metadata models, are XML files that define the types of transaction processes, service functions, table structures, and error code metadata in the project. Output data: PlantUML formatted text, a standard PlantUML flowchart syntax description; draw.io structured data, conforming to draw.io XML or JSON standard data formats; manim animation scripts, Python code files, using the manim library for animation generation; Internal structure: Preprocessing layer: standardizes semi-structured text, extracts core events, actions, and object relationships, and uses regex-based keyword extraction and structural decomposition; Semantic construction layer: calls the LLM model to generate interpretation results from the preprocessed structured text content; Format mapping layer: maps the output format syntax to the syntax structure required by PlantUML, draw.io, and manim; Output generation layer: finally serializes to the corresponding file format, and performs syntax concatenation and file encapsulation according to the target format.

5. A system for building large, production-ready code models, characterized in that, It includes a processor and a memory; the memory is used to store program code and transfer the program code to the processor; the processor is used to execute the method of any one of claims 1-4 according to the instructions in the program code.

Images