Rag and business logic based knowledge capturing method, device, equipment and medium

Abstract

This invention relates to the field of artificial intelligence technology and discloses a knowledge capture method, apparatus, device, and medium based on RAG and business logic. The method includes: responding to code submissions, detecting changes in code, identifying patterns, generating functional descriptions, pushing confirmation tasks carrying the descriptions, and obtaining responses; generating two sets of logical triples based on the changed code and functional descriptions respectively, and verifying consistency through semantic equivalence comparison; after successful verification, associating the two sets of triples with equivalent values, using at least one set as the knowledge to be added to the database, performing multi-source retrieval and conflict determination; storing the determination results in a multimodal knowledge base, establishing associations with historical versions to complete updates; responding to natural language queries, retrieving relevant knowledge fragments from the updated knowledge base as context input to a large language model, and generating response results. This invention can be applied to business scenarios such as fintech, achieving automatic capture of business logic, conflict detection, and intelligent question answering through mandatory knowledge confirmation and cross-validation mechanisms.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a knowledge capture method, apparatus, device, and medium based on RAG and business logic. Background Technology

[0002] Currently, the business logic and functional processing knowledge of enterprise software systems primarily relies on the personal memories or scattered document records of developers, testers, or product managers for management. This model, heavily dependent on "human brain" and "conscious behavior," constitutes the primary technical challenge of enterprise software engineering asset management: the risk of tacit knowledge loss. Once relevant personnel leave, change positions, or experience memory lapses, a large number of uncoded, critical judgment rules and processing procedures are lost, leading to system maintenance difficulties and soaring communication costs. Although various technical approaches exist within the industry attempting to solve this problem, each has its own significant technical limitations.

[0003] First, traditional document management solutions, such as Confluence, Notion, and Yuque, suffer from a complete disconnect between knowledge production and code implementation. These solutions rely on developers manually writing technical documentation and wikis. Lacking a mandatory linkage mechanism with code changes, the documentation is almost impossible to update synchronously with code iterations, compromising accuracy and timeliness, resulting in an extremely low actual implementation rate (less than 20% according to industry statistics). Second, while code commenting and automated documentation generation solutions (such as Doxygen and Swagger) improve the correlation between documentation and code, their technical capabilities are limited to the interface level (such as API parameters and return values), failing to capture deeper, higher-order logic such as "business rules," "state machine transitions," and "strategy selection." More importantly, comments still rely on manual writing, which also suffers from the serious problem of "written comments but with incorrect logic."

[0004] Furthermore, with the development of large language models, knowledge-based question-answering solutions based on RAG have emerged. While this technology achieves natural language interaction, the quality of its underlying knowledge base depends entirely on the quality of the existing input data, resulting in an inherent "garbage in, garbage out" flaw. More importantly, these solutions can only passively respond to user questions, lacking the ability to proactively identify knowledge gaps or conflicts, and cannot verify the accuracy of the answers generated by the large model, making them unsuitable for rigorous enterprise-level business logic management. On the other hand, code knowledge graph solutions based on AST analysis focus on parsing the syntactic structure of code, extracting only technical "call logic" such as function calls and dependencies, failing to understand the business semantics behind the code (such as "special rules during promotional periods"), and the output is mostly in the form of technical charts, lacking natural language interaction capabilities usable by non-technical personnel.

[0005] In the fintech field, the core challenge facing existing business logic knowledge management (RAG) technologies is the inherent and dynamic nature of risk control rules and trading strategies. Financial systems frequently adjust business rules such as risk control thresholds, credit limit calculations, and anti-fraud strategies, often accompanied by stringent compliance audit requirements. Existing technologies rely on developers' memories or scattered documentation documenting the reasons for rule changes. Once personnel change, a significant amount of critical decision-making logic is lost, making it difficult to trace "why it was designed this way" during system maintenance. Simultaneously, code-level comments cannot capture semantic-level context such as "a strategy being temporarily activated under specific market conditions," while traditional RAG solutions lack proactive conflict detection of historical rules, making them highly susceptible to "logic breaks" during compliance audits or incident tracing, leading to serious financial compliance and operational risks. Summary of the Invention

[0006] The main objective of this invention is to provide a knowledge capture method, apparatus, device, and storage medium based on RAG and business logic, aiming to solve the technical problems in the prior art where business logic knowledge capture relies on manual labor, has poor accuracy and timeliness, and lacks proactive conflict detection and version tracing capabilities.

[0007] To achieve the above objectives, this invention provides a knowledge capture method based on RAG and business logic, comprising: In response to a code commit event, the system detects changed code and identifies the change pattern, generates a functional description based on the change pattern, pushes a confirmation task carrying the functional description to the development end, and obtains the development end's response information to the confirmation task. The business logic of the modified code is parsed to generate a first set of logical triples. Based on the response information, the business logic of the function description is parsed to generate a second set of logical triples. The first set of logical triples and the second set of logical triples are semantically equivalent. The consistency between the modified code and the function description is verified based on the comparison results. After verification, the first set of logical triples and the second set of logical triples are equivalently associated, and at least one logical triple from the first set of logical triples and / or at least one logical triple from the second set of logical triples are taken as knowledge to be added to the database. Based on the RAG retrieval enhancement generation mechanism, multi-source retrieval is performed on the knowledge to be added to the database, and conflict determination is performed on the multi-source retrieval results to generate conflict determination results. Based on the conflict determination result, the knowledge to be added to the database is stored in the multimodal knowledge base. During storage, the database is queried to see if there is a historical version corresponding to the knowledge to be added. Based on the query result, a version association relationship is established between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. In response to a natural language question, knowledge fragments related to the natural language question are retrieved from the updated multimodal knowledge base, and the relevant knowledge fragments are used as context input to the large language model to generate a response.

[0008] Furthermore, to achieve the above objectives, the present invention provides a knowledge capture device based on RAG and business logic, comprising: The betting capture module is triggered in response to code commit events, detects code changes and identifies change patterns, generates a function description based on the change pattern, pushes a confirmation task carrying the function description to the development end, and obtains the development end's response information to the confirmation task. The double-blind cross-validation module is used to parse the business logic of the modified code, generate a first set of logical triples, parse the business logic of the function description based on the response information, generate a second set of logical triples, perform semantic equivalence comparison between the first set of logical triples and the second set of logical triples, and verify the consistency between the modified code and the function description based on the comparison results. The reverse lookup conflict warning module is used to, after verification, equivalently associate the first set of logical triples with the second set of logical triples, and take at least one logical triple from the first set of logical triples and / or at least one logical triple from the second set of logical triples as knowledge to be added to the database. Based on the RAG retrieval enhancement generation mechanism, it performs multi-source retrieval on the knowledge to be added to the database, performs conflict determination on the multi-source retrieval results, and generates conflict determination results. The tracking storage module is used to store the knowledge to be added to the database into the multimodal knowledge base according to the conflict determination result. When storing, it queries the historical knowledge base to see if there is a historical version corresponding to the knowledge to be added. Based on the query result, it establishes a version association relationship between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. The intelligent question answering module is used to respond to natural language questions by retrieving knowledge fragments related to the natural language questions from the updated multimodal knowledge base, inputting the relevant knowledge fragments as context into the large language model, and generating a response result.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a knowledge capture program based on RAG and business logic stored in the memory and executable on the processor, wherein when the knowledge capture program based on RAG and business logic is executed by the processor, it implements the steps of the knowledge capture method based on RAG and business logic as described above.

[0010] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a knowledge capture program based on RAG and business logic, wherein when the knowledge capture program based on RAG and business logic is executed by a processor, it implements the steps of the knowledge capture method based on RAG and business logic as described above.

[0011] Beneficial Effects: This invention relates to the field of artificial intelligence technology and discloses a knowledge capture method, apparatus, device, and medium based on RAG and business logic. The method includes: responding to code submissions, detecting changes in code, identifying patterns, generating functional descriptions, pushing confirmation tasks carrying the descriptions, and obtaining responses; generating two sets of logical triples based on the changed code and functional descriptions respectively, and verifying consistency through semantic equivalence comparison; after successful verification, associating the two sets of triples with equivalent values, using at least one set as the knowledge to be added to the database, performing multi-source retrieval and conflict determination; storing the results in a multimodal knowledge base, establishing associations with historical versions to complete updates; responding to natural language queries, retrieving relevant knowledge fragments from the updated knowledge base as context input to a large language model, and generating response results. This invention can be applied to business scenarios such as fintech. It forces the capture of business logic through a code submission-triggered betting mechanism, ensures code and semantic consistency through double-blind verification, and adds the knowledge to the database after RAG conflict detection. It also establishes version associations to trace the evolution history, helping to achieve automated capture, verification, and retention of business logic knowledge, effectively improving the accuracy and traceability of knowledge management. Attached Figure Description

[0012] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a knowledge capture method based on RAG and business logic in one embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the knowledge capture method based on RAG and business logic according to the present invention. Figure 3 This is a flowchart illustrating step S100 in one embodiment of the knowledge capture method based on RAG and business logic of the present invention. Figure 4 This is a flowchart illustrating step S200 in one embodiment of the knowledge capture method based on RAG and business logic of the present invention. Figure 5 This is a flowchart illustrating step S300 in one embodiment of the knowledge capture method based on RAG and business logic of the present invention. Figure 6 This is a flowchart illustrating step S400 in one embodiment of the knowledge capture method based on RAG and business logic of the present invention. Figure 7This is a schematic diagram of the functional modules of a preferred embodiment of the knowledge capture device based on RAG and business logic of the present invention; Figure 8 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 9 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0013] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0014] The knowledge capture method based on RAG and business logic provided in this invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can respond to code submissions from the client, detect changes in the code, identify patterns to generate functional descriptions, push confirmation tasks carrying the descriptions, and obtain responses. Based on the changed code and functional descriptions, two sets of logical triples are generated, and semantic equivalence comparison is used to verify consistency. After successful verification, the two sets of triples are equivalently associated, with at least one set used as the knowledge to be added to the database. Multi-source retrieval and conflict determination are performed. The results are stored in a multimodal knowledge base, and an association with historical versions is established to complete the update. In response to natural language queries, relevant knowledge fragments are retrieved from the updated knowledge base as context input to a large language model to generate a response. This invention can be applied to business scenarios such as fintech. By triggering a betting mechanism through code submission, business logic is forcibly captured. Double-blind verification ensures code and semantic consistency. After RAG conflict detection, the code is added to the database, and version associations are established to trace the evolution history. This helps to achieve automated capture, verification, and retention of business logic knowledge, effectively improving the accuracy and traceability of knowledge management. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0015] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the knowledge capture method based on RAG and business logic provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0016] like Figure 2 As shown, the knowledge capture method based on RAG and business logic proposed in this invention includes the following steps: S100. In response to the code commit event, detect the changed code and identify the change pattern, generate a function description according to the change pattern, push the confirmation task carrying the function description to the development end, and obtain the response information of the development end to the confirmation task. S200. Parse the business logic of the changed code to generate a first set of logical triples. Based on the response information, parse the business logic of the function description to generate a second set of logical triples. Perform a semantic equivalence comparison between the first set of logical triples and the second set of logical triples. Verify the consistency between the changed code and the function description based on the comparison results. S300. After verification, the first set of logical triples and the second set of logical triples are equivalently associated, and at least one logical triple in the first set of logical triples and / or at least one logical triple in the second set of logical triples are taken as knowledge to be added to the database. Based on the RAG retrieval enhancement generation mechanism, multi-source retrieval is performed on the knowledge to be added to the database, and conflict determination is performed on the multi-source retrieval results to generate conflict determination results. S400. Based on the conflict determination result, store the knowledge to be added to the multimodal knowledge base. When storing, query whether there is a historical version in the historical knowledge base that corresponds to the knowledge to be added. Based on the query result, establish the version association relationship between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. S500: In response to a natural language question, retrieve knowledge fragments related to the natural language question from the updated multimodal knowledge base, input the relevant knowledge fragments as context into the large language model, and generate a response result.

[0017] In this embodiment, in response to a developer submitting code to the code repository, the challenge task generation engine is automatically triggered. This engine first detects the changed code, identifies the change pattern (such as adding conditional branches, modifying loop logic, adjusting state transitions, etc.), and automatically generates a functional description based on the identification results. Subsequently, the system pushes a confirmation task carrying this functional description to the development end, requiring the developer to confirm or reject the system-generated functional description. After the developer responds, the system updates the user's trust score based on their response. This mechanism is the core embodiment of transforming knowledge recording from an "optional action" for developers into a "mandatory hurdle" in the development process.

[0018] While acquiring the response information from the development side, a double-blind adversarial verification engine is launched. This engine comprises two independent agents: a code agent and a semantic agent. The code agent takes the modified code as input and analyzes it through an abstract syntax tree, focusing on logical elements such as conditional statements (if / switch), loops (for / while), state transitions, exception handling, and strategy selection. It ultimately outputs structured "logical triples" in the format [condition, action, branch flow]. The semantic agent takes natural language functional descriptions as input and performs semantic parsing to extract business logic elements. It supports semantic equivalence processing such as synonym replacement and word order adjustment, ultimately outputting logical triples in the same format as the code agent. After both agents complete their independent operations, the first set of logical triples (from the code) and the second set of logical triples (from the semantic agent) are fed into a comparator for semantic equivalence comparison. This comparator does not perform simple string comparisons, but rather semantic equivalence comparisons. For example, "amount > 5000" and "amount greater than five thousand" are considered equivalent. It also supports logical reasoning, such as the code "A > 10 and B < 5" being considered equivalent to the description "A is greater than 10 and B is less than 5". Through this comparison result, the consistency between the changed code and the functional description is verified.

[0019] After successful verification, the first set of logical triples and the second set of logical triples are equivalently associated, and at least one logical triple from the first set and / or at least one logical triple from the second set of logical triples is selected as the knowledge to be added to the database. At this point, the RAG (Retrieval-Augmented Generation) proactive reverse lookup engine is activated to proactively perform multi-source retrieval before knowledge is added to the database. This engine simultaneously retrieves three channels: semantic description, code AST (Abstract Syntax Tree), and Git (distributed version control system) commit information. The results from these three channels are fused and sorted through cross-validation, rather than simply concatenated. Based on the multi-source fusion retrieval results, conflict determination is performed. Conflict determination includes four rules: Completely identical (the exact same logic already exists in the historical database, marked as known logic, credit score increases slightly); Similar but different (similar logic but conditions or actions change, generating a conflict alert, displaying a comparison of the old and new versions, requiring the developer to explain); Completely different (no similar logic exists in the historical database, marked as new logic, credit score increases); Contradictory versions (multiple versions of the same logic exist in the historical database but their descriptions contradict each other, generating a contradiction alert, triggering manual arbitration). The search process also includes a time dimension, supporting the specification of "searching for logic from 2023," and the returned results include timestamps to help determine the relationship between old and new knowledge.

[0020] Based on the conflict determination results, the knowledge to be added is stored in the multimodal knowledge base. During storage, the system queries the historical knowledge base to see if a corresponding historical version exists. If a historical version exists, a parent-child relationship is established, with the new node pointing to the old node; if no historical version exists, it is marked as the root node. Simultaneously, change information is recorded, including: description, old description (if any), reason for change, person making the change, time of change, Git commit, change order, etc. Finally, an evolutionary index is built, supporting queries by time for current logic, historical logic, reason for change, person making the change, evolutionary path, etc. The multimodal knowledge base employs a structured storage method combining knowledge graphs, vector databases, and relational databases.

[0021] It also includes a historical logic reverse engineering module for comprehensive "historical logic mining" of existing code. This module obtains the full and incremental codebases through Git historical commits, uses a difference analysis engine to compare versions, and then uses an AST parser to transform the code into a structured representation. AI logic extraction is then performed, covering conditional branch extraction (if / else, switch, ternary operation), loop logic extraction (for, while, foreach), data flow extraction (parameter passing, return values, exception handling), business rule extraction (permission judgment, amount calculation, state transition), and context association (method call chain, class inheritance relationship, interface implementation). Finally, a logic validator performs single-item verification, conflict detection, and integrity checks, and stores verified knowledge in the knowledge base. This module also supports periodic full or incremental crawling for continuous updates to the knowledge base.

[0022] When a user asks a question in natural language, relevant knowledge fragments are retrieved from the updated multimodal knowledge base. The retrieval process combines semantic description, code structure, and evolutionary history, using the retrieved knowledge fragments as context input to the large language model, ultimately generating a natural language response. This completes the entire closed loop from "active capture → cross-validation → intelligent storage → natural question answering."

[0023] This embodiment constructs a closed-loop system of "betting trigger—double-blind verification—RAG reverse lookup—evolutionary storage—intelligent question answering." Upon code submission, a functional description is forcibly generated and confirmation is pushed; logical triples are generated through dual agents using AST and semantic parsing for cross-validation; before storage, multi-source retrieval and conflict determination ensure knowledge uniqueness; during storage, version parent and child nodes are associated to form a traceable timeline; finally, enhanced RAG achieves highly reliable natural language question answering. In terms of effectiveness, it transforms passive recording into active capture, realizing "updating upon code submission," significantly improving retention rate and accuracy, and effectively solving the knowledge gap problem caused by personnel turnover.

[0024] In fintech operations, core logic such as payment routing, risk control decisions, credit limit calculation, and compliance verification undergoes frequent changes and is subject to stringent regulations. This system can be embedded into the development pipeline: after developers submit code to adjust risk control rules, the system forcibly generates a change description (e.g., "anti-fraud threshold adjusted from 5000 to 10000"), which is double-blindly verified to ensure the description is equivalent to the code. Then, RAG (Regulatory Information Aggregator) is used to retrospectively check the downstream strategies that have been affected historically. If a conflict is found (e.g., affecting another risk control model), an alert is immediately triggered and the process is blocked. During storage, the system automatically associates the original version with the reason for the change (e.g., work order number, regulatory document number), forming a complete compliance audit timeline. When business personnel ask, "What is the current credit card credit granting strategy?", the system accurately retrieves the version source and the basis for the change from the knowledge base, supporting rapid response to regulatory inquiries. New employees can quickly master core business rules through conversational Q&A, eliminating reliance on word-of-mouth from experienced staff, significantly reducing the operational risks and compliance costs of the financial system.

[0025] In one embodiment, S100 includes: S101. Detect the changes in the files and code of the code commit event, and determine the changed code based on the changes in the files and code. S102. Parse the change code and identify the change pattern; S103. Based on the context information of the changed code and the change mode, generate a natural language description and use the natural language description as the initial functional description; S104. Push the knowledge record confirmation task carrying the initial functional description to the development end; S105. Obtain the response information of the development end to the knowledge record confirmation task, and update the trust score of the development end according to the response information and historical response records.

[0026] In this embodiment, as Figure 3 As shown, after a code commit event is triggered, the changes are first precisely identified and analyzed. Specifically, the changes to the relevant files and code involved in the commit event are detected. By comparing the code versions before and after the commit, the changed code segments, i.e., the "modified code," are accurately located. Subsequently, this modified code is analyzed in depth to identify its change pattern, such as whether a conditional branch has been added, loop logic has been modified, or state transitions have been adjusted. This identification process is not a simple text matching but a structured analysis based on the Abstract Syntax Tree (AST, a tree-like abstract representation of the source code's syntactic structure), thereby accurately capturing the essence of the code changes.

[0027] After obtaining the changed code and its pattern, the system automatically generates a natural language description based on the contextual information of the changed code, including its class, method, call chain, and related comments or historical commit records, combined with the identified change pattern. This description serves as the "initial functional description" for the change. This step leverages the semantic understanding and generation capabilities of the Large Language Model (LLM) to transform technical code changes into a business logic description readable by business users.

[0028] Next, a knowledge record confirmation task carrying this initial functional description is pushed to the development team. This push action is a key part of the "betting mechanism": developers are not passively receiving information, but are required to confirm or reject the functional description. This task is usually presented through development tools (such as IDE plugins, code reviews, or instant messaging bots) to ensure that developers can respond conveniently in their daily workflow.

[0029] Finally, the developer's response to the confirmation task will be obtained. The developer's response (confirmation, rejection, or modification) not only serves as the basis for knowledge entry into the repository but also updates their personal "trust score." The developer's trust score is dynamically adjusted based on this response and historical response records. For example, a developer with a consistently accurate confirmation history will see their trust score rise, potentially leading to higher initial confidence in their subsequent knowledge submissions; conversely, frequent rejections or incorrect confirmations will result in a decrease in their trust score. This mechanism links the responsibility for the accuracy of knowledge recording to the developer's personal credit, transforming "knowledge recording" from an optional action into a mandatory hurdle in the development process.

[0030] In this embodiment, when code is submitted, the system automatically detects changed files and differences, locates the changed code, and parses its change pattern (such as adding conditional branches, modifying loop logic, adjusting state transitions, etc.). Based on the code context and pattern, a natural language functional description is generated as the initial description, and a confirmation task is pushed to the development team. After obtaining the developer's response, their trust score is dynamically updated based on historical response records. Knowledge recording is transformed from an "optional action" into a "mandatory checkpoint," driving developers to actively participate in knowledge confirmation through a credit score-linked approach, ensuring the quality of knowledge capture from the source.

[0031] In fintech scenarios, core logic such as payment clearing, risk control strategies, and credit limits are subject to frequent and risk-sensitive adjustments. This system can be integrated into the development pipeline: when developers submit code involving changes to risk control rules, the system automatically identifies the change pattern (e.g., "anti-fraud decision threshold adjusted from 5000 to 10000") and generates an initial functional description, pushing it to the developer for confirmation. If developers respond accurately over a long period, trust points accumulate, and subsequent submissions enjoy higher initial confidence levels; if there are frequent false confirmations, trust points decrease and additional manual review is triggered. This mechanism is particularly suitable for regulatory reporting scenarios—every rule change is forcibly recorded, forming a traceable confirmation ledger. When regulators inquire "when the threshold was adjusted and who confirmed it," the system can directly retrieve trust point records and confirmation history. For frequently changing modules such as liquidity risk measurement and anti-money laundering strategies, the trust point mechanism can also identify key personnel with high knowledge contributions, assisting managers in resource allocation and training decisions, reducing compliance risks while improving team efficiency.

[0032] In one embodiment, S200 includes: S201. Parse the change code and extract the conditional branch structure, loop structure, state transition node, exception handling node and strategy selection node from the change code; S202. Generate a first set of logical triples based on the conditional branching structure, loop structure, state transition node, exception handling node, and strategy selection node. S203. Perform natural language semantic parsing on the functional description to extract the business logic elements in the functional description; S204. Perform semantic equivalence generalization processing on the business logic elements by synonym replacement and word order adjustment, and generate a second set of logical triples based on the processing results. S205. Perform a semantic equivalence comparison between the first set of logical triples and the second set of logical triples; S206. If the first set of logical triples and the second set of logical triples are determined to be semantically equivalent, then the functional description consistency verification is passed. S207. If it is determined that the first set of logical triples and the second set of logical triples are semantically inequivalent, a verification conflict alarm is generated and returned to the development end.

[0033] In this embodiment, as Figure 4As shown, in the implementation of the double-blind adversarial verification engine, the modified code is first subjected to structured parsing. This parsing is not a simple text scan, but a deep analysis based on an Abstract Syntax Tree (AST, which is a tree-like abstract representation of the source code syntax structure; it does not directly parse the original code text, but parses the structured syntax tree of the code). Five types of key logical nodes are precisely extracted from the AST: conditional branching structures (such as if / else, switch statements), loop structures (such as for, while, foreach statements), state transition nodes (such as assignment and switching of state enumerations), exception handling nodes (such as try-catch blocks), and strategy selection nodes (such as strategy routing logic in strategy patterns). The extraction of each type of node is accompanied by complete contextual information, including the code position of the node, the variables and constants involved, the jump target, etc., thereby ensuring that the subsequently generated logical triples have a complete semantic foundation.

[0034] Based on the extraction results above, each type of logical node is transformed into a structured "logical triple," with the format uniformly set to "[condition, action, branch direction]." For example, an if conditional statement is transformed into a "condition" that is the judgment expression, an "action" that is the execution body, and a "branch direction" that is the target location of true or false. These triples constitute the first set of logical triples, representing the code agent's "understanding" of the changed code.

[0035] Simultaneously, natural language semantic parsing is performed on the functional description. This process includes Chinese word segmentation, dependency parsing, and semantic role labeling to extract business logic elements, such as business entities (e.g., "order," "user"), business actions (e.g., "review," "timeout closure"), business conditions (e.g., "amount greater than 5000," "status is paid"), and business results (e.g., "entering manual review," "automatic refund"). After initial extraction, the above elements undergo semantic equivalence generalization processing. Specific methods include synonym substitution (e.g., replacing "greater than" with equivalent expressions such as "exceeds" or "higher than") and word order adjustment (e.g., adjusting "amount greater than 5000" to "5000 is less than the amount" or "amount exceeds five thousand") to cover diverse expressions in natural language. After this generalization processing, the results are also transformed into logical triples with a consistent format, forming a second set of logical triples, representing the semantic agent's "understanding" of the functional description.

[0036] Subsequently, the first and second sets of logical triples are fed into a comparator for semantic equivalence comparison. This comparison is not a simple string or numerical equality check, but rather performs semantic-level equivalence verification. For example, the condition "amount > 5000" in the code triple is considered equivalent to "amount greater than five thousand" in the semantic triple. Furthermore, the comparator supports logical reasoning capabilities, enabling it to recognize the equivalence relationship between "A > 10 and B < 5" and "A is greater than 10 and B is less than 5," even if the two are completely different at the character level. During the comparison process, corresponding triples in the two sets are matched one by one, and the semantic similarity is considered across three dimensions: conditional expression, action type, and branch flow, ultimately providing an overall equivalence determination.

[0037] If the first set of logical triples is determined to be semantically equivalent to the second set of logical triples, the functional description consistency verification passes, and the changed code and the functional description confirmed by the developer are consistent at the business logic level. If the semantics are determined to be inequivalent, it indicates that there is a discrepancy between the code implementation and the functional description. This may be due to the code change not being fully described, or the functional description failing to accurately reflect the code change. A verification conflict alarm is then generated, and this alarm, along with specific details of the difference (such as which triples do not match and what the difference type is), is returned to the development team. The developer is required to review and correct the functional description or code implementation, thereby preventing inconsistent knowledge from flowing into the knowledge repository.

[0038] This stage employs a double-blind adversarial verification mechanism. The system parses the abstract syntax tree of the modified code, extracting five types of nodes: conditional branches, loops, state transitions, exception handling, and strategy selection, thereby generating a first set of logical triples. Simultaneously, the functional description confirmed by the developer undergoes semantic parsing, generating a second set of logical triples after synonym replacement and word order adjustment. The consistency between the two is verified through semantic equivalence comparison—verification passes if they are equivalent, otherwise an alert is issued and returned. This code-based verification of the manual description ensures that the knowledge stored in the database is "strictly consistent with the description," preventing the problem of a disconnect between functional descriptions and actual code implementation.

[0039] In fintech operations, modules such as compliance verification, risk control rules, and billing logic require extremely high accuracy. Inconsistencies between description and implementation can directly lead to financial losses or regulatory penalties. This system can be embedded in core development processes: when developers modify anti-money laundering alert logic, the system automatically generates a logical triple such as "condition: transaction amount exceeds 50,000, action: report suspicious activity," and performs bidirectional verification with the developer's confirmed description. If the code actually implements "amount exceeds 100,000" but describes it as "exceeds 50,000," the system immediately generates a verification conflict alarm and prevents the knowledge from being added to the database, requiring the developer to correct it. For complex businesses such as cross-border payment exchange rate calculations and dynamic credit limit adjustments, the code may contain multiple nested conditions and multiple state transitions. Double-blind verification can accurately capture branches omitted in the description. For example, if the developer describes the main process but ignores the exception handling branch, the system will supplement the complete description accordingly. Automating the "reconciliation" between manual descriptions and code ensures the accuracy and traceability of core financial logic, providing credible knowledge for regulatory audits.

[0040] In one embodiment, S300 includes: S301. Perform semantic vector retrieval based on the natural language description of the knowledge to be added to the database; S302. Perform code structure feature retrieval based on the code structure of the knowledge to be added to the database; S303. Retrieve historical commit information based on the metadata of the code commit event; S304. Perform cross-validation on the three search results, and adjust the confidence level of each search result by weighting based on the cross-validation results; S305. Perform fusion and sorting based on the weighted search results, and determine the matching type between the knowledge to be added to the database and the historical knowledge base based on the fusion and sorting results and the cross-validation results. S306. When the matching type of the knowledge to be added to the historical knowledge base is the same as that of the knowledge to be added, the knowledge to be added to the knowledge base is marked as known logic. S307. When the matching type between the historical knowledge base and the knowledge to be added is logically similar but the conditions or actions are different, a conflict alarm and a comparison of old and new information are generated. S308. When the matching type of the knowledge to be added to the historical knowledge base is not the same as that of the knowledge to be added, the knowledge to be added to the knowledge base is marked as newly added logic. S309. When the matching type between the historical knowledge base and the knowledge to be added to the database is logically contradictory, a contradiction alarm is generated.

[0041] In this embodiment, as Figure 5As shown, after successful verification and the generation of knowledge to be added to the database, the RAG proactive reverse lookup engine is activated to perform proactive auditing before knowledge is added to the database. This engine initiates searches in parallel from three independent channels. The first channel performs semantic vector retrieval based on the natural language description of the knowledge to be added: the business logic description of the knowledge to be added is converted into vectors using an embedding model (a neural network model that converts text into high-dimensional vector representations), and then historical knowledge fragments with similar semantics are retrieved from the vector database. The second channel performs code structure feature retrieval based on the code structure of the knowledge to be added: the abstract syntax tree (AST) structure features corresponding to the knowledge to be added are extracted, including function call chains, conditional branch topologies, and nested loop levels, and historical logical nodes with similar code topologies are retrieved from the knowledge graph. The third channel performs historical commit information retrieval based on the metadata of code commit events: the Git commit hash, commit time, committer, commit description, and associated ticket number are extracted for this commit, and historical commit records of the same module or author are retrieved from the relational database as auxiliary association clues.

[0042] After the search results from the three channels each return a list of candidate knowledge, they proceed to the cross-validation stage. The core of this stage is to mutually verify the three results: for example, if semantic retrieval matches historical knowledge, and code structure retrieval also points to the same historical knowledge, then the match result receives a high initial confidence score; conversely, if the search results from the three channels point to different historical knowledge, the confidence score of each result is weighted and adjusted downwards. The specific implementation of cross-validation is as follows: for each candidate result, the matching score for each of the three channels is calculated separately, and then the scores are dynamically weighted according to the "majority consensus principle," meaning that candidate results that match all three channels receive the highest weight, those matching two channels receive the next highest weight, and those matching only one channel receive the lowest weight. After weighting adjustment, each candidate result receives a fused confidence score.

[0043] Next, all candidate results are merged and ranked according to the weighted confidence scores, with the most relevant historical knowledge ranked first. Based on the merged ranking results and the matching details of each channel recorded during cross-validation, the matching type between the knowledge to be added and the historical knowledge base is determined. The matching type is divided into four categories: logically identical, logically similar but different, logically different, and logically contradictory. When the most matching historical knowledge in the merged ranking is completely consistent with the knowledge to be added in the three dimensions of condition expression, action type, and branch flow (after semantic equivalence judgment), it is judged as "logically identical", the knowledge to be added is marked as known logic, and the developer's credit score is slightly increased. When the two are similar in core logic framework, but there are clear differences in condition thresholds or action parameters (e.g., the historical version is "amount > 5000", the current version is "amount > 10000"), it is judged as "logically similar but different", a conflict alarm is generated, and new and old comparison information is constructed (the old logic is displayed side by side), and pushed to the development side to request supplementary change instructions. When no historical knowledge in the fusion ranking results reaches a similarity threshold in semantics or structure with the knowledge to be added to the database, it is judged as "logically different," and the knowledge to be added to the database is marked as new logic, increasing its credit score. When the search finds multiple versions of the same business logic in the historical database but with contradictory descriptions (e.g., two conflicting records in the same module: "order timeout is 30 minutes" and "order timeout is 24 hours"), it is judged as "logical contradiction," generating a contradiction alert and triggering a manual arbitration process, where senior developers or architects intervene to adjudicate. The entire search and judgment process includes a time dimension; each piece of historical knowledge returned carries its version timestamp, allowing for filtering or comparison of old and new relationships based on time, ensuring the timeliness of conflict detection.

[0044] This step utilizes RAG's proactive reverse lookup mechanism. Before knowledge is added to the database, the system performs semantic vector retrieval, code structure feature retrieval, and submitted metadata retrieval in parallel. The results from these three channels are cross-validated and weighted fusion sorted to determine the matching type: logically identical results are marked as known; similar differences trigger conflict alerts and comparisons between old and new data; logically different results are counted as new; and logical contradictions trigger conflict alerts. Conflicts are proactively intercepted before knowledge is added to the database, ensuring internal consistency and traceability.

[0045] In fintech scenarios, the same business logic (such as "credit card limit adjustment rules") may be maintained in parallel by multiple teams, which can easily lead to version conflicts or logical contradictions. This system can be applied to core pricing engines, anti-fraud models, or compliance verification modules: When a team submits new rule code, the RAG proactive reverse lookup engine will automatically compare it with the historical knowledge base before storing it. If a similar but conditionally different rule is detected (such as "single transaction limit changed from 50,000 to 100,000"), a new and old comparison alert will be immediately generated and pushed to both teams, requiring them to explain the reason for the change and preventing unexpected changes; if a contradictory version is detected (such as two records for the same business, "reported after three days of overdue payment" and "reported after five days of overdue payment"), a contradiction alert will be directly triggered and escalated to the architect for manual arbitration. This can effectively avoid rule conflicts caused by information silos and reduce compliance risks. At the same time, all conflict records and arbitration opinions are automatically stored and archived, providing a complete chain of decision-making evidence for subsequent regulatory audits.

[0046] In one embodiment, S400 includes: S401. When storing the knowledge to be stored, extract the logical identifier of the knowledge to be stored, and use the logical identifier as an index to query whether there is a historical node with the same logical identifier in the historical knowledge base. S402. When there are historical nodes with the same logical identifier, the knowledge to be added to the database is used as a new node to establish a parent-child relationship pointing to the historical node. S403. When there is no historical node with the same logical identifier, mark the knowledge to be added to the database as the root node; S404. Record the change information of the knowledge to be added to the database and construct an evolution index to complete the update of the multimodal knowledge base.

[0047] In this embodiment, as Figure 6 As shown, after the knowledge to be added to the database passes the conflict determination, it officially enters the storage and evolution tracking stage. The first step in the storage process is to extract the logical identifier of the knowledge to be added to the database. This identifier is a unique ID generated based on the semantic features of the business logic and the code structure features. For example, a hash algorithm is used to perform a digest calculation on the normalized representation of the logical triple (the normalized conditional expression, action type, and branch flow) to ensure that the same business logic has the same logical identifier in different versions, while different logics have different identifiers.

[0048] Then, using this logical identifier as an index, a precise query is performed in the historical knowledge base to determine if a historical node with the same logical identifier exists. If the query finds a match, it indicates that the business logic is not appearing for the first time, but may be a revision or optimization of the same logic. The knowledge to be added to the knowledge base is then treated as a new node, and a parent-child relationship is established pointing to this historical node; that is, the new node's "parent pointer" points to the old node, thus forming a traceable version chain in the knowledge graph. If the query does not find a match, it indicates that the logic has no record in the historical knowledge base. The knowledge to be added to the knowledge base is then marked as a root node, serving as the starting point for the evolution of this business logic.

[0049] Regardless of the storage method used, complete change information for the knowledge to be added to the repository will be recorded synchronously. The content structure of the change information includes: a logical description of the current version (in natural language), a description of the old version (recorded only when parent-child relationships exist), the reason for this change (usually extracted from the commit message or associated work order), the person making the change (i.e., the developer who committed the code), the change time (timestamp accurate to the second), the associated Git commit hash, and the associated work order or requirement number. This change information, along with the logical node itself, is stored in the multimodal knowledge base.

[0050] After completing the node creation and change information recording, an evolution index is built for each logical node. This index is a multi-level index structure based on a timeline, supporting fast queries in the following dimensions: querying the current effective version of a business logic by time range, tracing back historical logic by version number, filtering all logic modified by a specific developer by the person making the change, searching the scope of impact by keywords related to the reason for the change, and tracing back the complete evolution path along the parent-child relationship. The construction of the evolution index makes the knowledge base no longer a static snapshot, but a historical asset library with complete time depth, thus providing reliable data support for subsequent scenarios such as "natural question answering" and "impact analysis". At this point, the knowledge to be added to the database has completed the entire process from verification to storage update.

[0051] In this embodiment, when storing knowledge to be added to the database, the system generates a unique logical identifier based on logical triples as an index and queries the historical knowledge base to see if a historical node with the same identifier exists. If it exists, a parent-child relationship is established, with the new node pointing to the old node; if it does not exist, it is marked as the root node. Simultaneously, the system records the change description, old description, changer, change time, Git commit, and ticket number to build an evolutionary index. This enables full version tracking of business logic, supports tracing back to any historical version along the timeline, and provides complete data support for problem localization and audit tracing.

[0052] In the fintech sector, core business logic such as credit approval rules, anti-fraud strategies, and pricing engines undergo frequent and heavily regulated changes. Misoperation in any version can lead to significant risks. This system's evolution tracking mechanism can be applied to version rollback and impact analysis scenarios. For example, when a bank adjusts its credit card limit approval rules, the system automatically detects that a historical version of this logic already exists during storage. It then creates a new node pointing to the old version and records the reason for the change (e.g., "regulatory requirement adjustment"), related work orders, and the information of the person making the change. When an anomaly occurs after the new rule goes live, risk management personnel can quickly query the complete change timeline of the business logic through the evolution index, accurately pinpointing the differences before and after the change, assisting in fault recovery. Simultaneously, during regulatory audits, the system can directly output the full evolution path of a business logic, including the decision-maker, time, and basis for each change, ensuring a complete closed-loop audit chain. For complex scenarios involving multiple versions, parent-child relationships can also be used to analyze the impact range of the same logic under different branches, supporting rollback decisions.

[0053] In one embodiment, the knowledge to be added to the database is stored in a multimodal knowledge base according to the conflict determination result. During storage, the system queries the historical knowledge base to see if a historical version corresponding to the knowledge to be added exists. Based on the query result, a version association relationship is established between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. The system also includes: The code repository's historical commit records are used to crawl the full code or incrementally changed code, and the full code or incrementally changed code is compared between versions to obtain a list of changed files and information on changed lines of code. Based on the list of changed files and the information on changed lines of code, the full code or incremental changed code is converted into a structured intermediate representation; The structured intermediate representation is parsed to extract conditional branching logic, loop logic, data flow logic, business rule logic, and context association logic; Logical triples are generated based on the conditional branching logic, loop logic, data flow logic, business rule logic, and context association logic, and a confidence level is generated for each logical triple. Perform single-item consistency verification on the logical triples, store the verified logical triples in the multimodal knowledge base, and associate them with version tags and timestamp tags. Mark logical triples with confidence scores below a preset threshold as pending confirmation.

[0054] In this embodiment, during the process of improving the multimodal knowledge base, a historical logic reverse engineering module is used to comprehensively mine the business logic of the existing code. This module first crawls the full code or incrementally changed code from the historical commit records of the code repository (such as Git). This process supports two modes: the initial run performs a full crawl to obtain a complete snapshot of all historical versions of the code repository; subsequent runs use incremental crawling, only pulling new commits since the last crawl. After obtaining the code, a difference analysis engine is used to compare the full code or incrementally changed code between versions, accurately identifying the list of changed files and changed lines of code involved in each commit, thereby locating the specific code segments that were added, modified, or deleted.

[0055] Based on the aforementioned list of changed files and changed lines of code, the full or incrementally changed code is converted into a structured intermediate representation. The core tool for this conversion is the AST parser (AST stands for Abstract Syntax Tree, a tree-like abstract representation of the source code syntax structure). It parses the original code text into a structured syntax tree, containing complete information such as node types, node levels, inter-node reference relationships, and variable scope. This allows subsequent analysis to no longer rely on text matching but instead be processed based on a structured code semantic model.

[0056] Subsequently, the structured intermediate representation is deeply analyzed to extract five categories of business logic elements: conditional branching logic (including all conditional judgment structures such as if / else, switch, and ternary operations), loop logic (including loop structures such as for, while, and foreach), data flow logic (including data flow paths such as parameter passing, return value mapping, and exception handling chains), business rule logic (including rules with clear business semantics such as permission judgment, amount calculation, and state transition), and context association logic (including dependencies and associations between code such as method call chains, class inheritance relationships, and interface implementation relationships). Each type of logic extraction is accompanied by its code location, the variables and constants involved, the jump target, and the reference relationships with other logic nodes.

[0057] Based on the five extracted logical elements, logical triples ([condition, action, branch flow]) are generated according to a unified format, and a confidence score is generated for each logical triple. The confidence score is calculated by considering multiple factors: the completeness of the code structure (e.g., whether there are complete comments), the complexity of the logic (simple conditions have higher confidence than multi-level nesting), the clarity of the contextual semantics (whether there are explicit business names), and the standardization of historical commit records (whether the commit description includes a business description). The confidence score ranges from 0 to 1, with a higher score indicating greater confidence in the accuracy of the logical triple.

[0058] After generating logical triples, the module proceeds to the verification and storage phase. First, a single-item consistency verification is performed on each logical triple, checking whether the extracted logic matches the original code implementation. This includes verifying whether the conditional expression in the triple actually exists in the code AST, whether the action corresponds to a valid code block, and whether the branch flow matches the actual jump target. Logical triples that pass the single-item consistency verification are stored in the multimodal knowledge base, associated with a version tag (corresponding Git commit hash) and a timestamp tag (commit time) to ensure that each knowledge entry is traceable. Logical triples with a confidence level below a preset threshold (e.g., 0.6) are not directly stored as confirmed knowledge; instead, they are marked as "pending confirmation," and a prompt message is generated for subsequent manual review by the development team. This module also supports periodic scheduling (e.g., daily or weekly) to continuously crawl new commits incrementally, ensuring continuous synchronization and updates between the knowledge base and the code repository.

[0059] This embodiment crawls full or incremental code from Git history records, locates changed files and lines of code through version comparison, and uses an AST parser to convert the code into a structured intermediate representation. From this, five types of logic are extracted: conditional branches, loops, data flow, business rules, and contextual relationships. Logical triples are generated based on these, and confidence levels are assigned. After single-item consistency verification, those that pass are associated with the version and timestamp and stored in the database, while those with low confidence are marked as awaiting confirmation. This achieves a comprehensive "archaeological excavation" of existing code, filling in gaps in historical knowledge and constructing a complete business logic knowledge graph.

[0060] In fintech scenarios, many existing systems have undergone years of iteration, with core business logic scattered throughout outdated code, and many original developers have left their posts, resulting in severe documentation deficiencies. This module can be applied to knowledge reconstruction and compliance self-checks of existing systems. For example, a payment institution needs to review all verification logic related to anti-money laundering transactions. The system automatically extracts rules such as "transactions exceeding 50,000 must be reported" from historical commits by crawling the entire code repository and generates confidence scores—high scores are given to well-commented and clearly structured logic; low scores are marked for complex nesting or lack of context, requiring manual verification. Simultaneously, during system upgrades or mergers, this module can compare logical differences between different versions, identify deleted or modified business rules, and avoid compliance blind spots due to accidental deletion. For new functions added due to regulatory requirements, incremental crawling can quickly confirm whether the relevant logic has been correctly implemented and stored. This helps financial institutions effectively revitalize legacy code assets, making tacit knowledge explicit, and reducing compliance risks and maintenance costs.

[0061] In one embodiment, performing a multi-dimensional quantitative evaluation of the multimodal knowledge base further includes: Traverse the total number of logical nodes stored in the multimodal knowledge base to obtain the estimated total number of business logic in the code library corresponding to the multimodal knowledge base; The ratio of the total number of logical nodes to the estimated total number of business logic nodes is used as the knowledge coverage rate. When the knowledge coverage rate is lower than a preset coverage threshold, low-coverage modules are marked and completion suggestions are generated. Traverse the stored logical nodes in the multimodal knowledge base, and count the number of verified nodes that have been verified and the number of historical versions associated with each logical node; The verification rate is calculated as the ratio of the number of verified nodes to the total number of logical nodes. Calculate the average number of historical versions as the version evolution depth; A comprehensive score for knowledge health is calculated based on the verification rate and the version evolution depth. When the overall health score of the knowledge is lower than the preset health threshold, the low health node is marked and the review process is triggered.

[0062] In this embodiment, after knowledge storage is completed, the knowledge asset quantification and evaluation stage is entered to achieve continuous monitoring of the knowledge base quality. First, the total number of logical nodes stored in the multimodal knowledge base is traversed. A logical node is the corresponding node in the knowledge graph for each independent business logic unit, and each node represents a complete logical triple and its associated version information. Simultaneously, the estimated total number of business logic units in the code repository corresponding to the knowledge base is obtained. This estimated value can be comprehensively estimated through dimensions such as the number of modules in the code repository, the number of API interfaces, and statistics on business function points involved in historical commits.

[0063] Subsequently, the ratio of the total number of logical nodes to the estimated total number of business logic nodes is calculated; this ratio is defined as the knowledge coverage rate. Knowledge coverage rate reflects the proportion of captured business logic to all expected business logic and is a core indicator for measuring the completeness of the knowledge base. When the knowledge coverage rate falls below a preset threshold, low-coverage modules are automatically marked. By analyzing the distribution of logical nodes in each module (such as the order module, payment module, and user module), modules with significantly lagging coverage are located, and completion suggestions are generated. These suggestions may include prompting developers to prioritize supplementing the core business logic of the module, or suggesting that testers perform targeted scenario coverage of the module to trigger more code path capture.

[0064] While assessing the completeness of knowledge, the internal quality of the knowledge base is further evaluated. All stored logical nodes are traversed, and the number of verified nodes is counted. Verified nodes are those marked as "verified" after double-blind adversarial verification or manual confirmation. Simultaneously, the number of historical versions associated with each logical node is counted, i.e., the number of version iterations each business logic has undergone since being added to the database. Based on these statistics, two derived metrics are calculated: the verification rate is the ratio of the number of verified nodes to the total number of logical nodes, reflecting the proportion of substantially verified knowledge in the knowledge base; the version evolution depth is the average of the number of historical versions of all logical nodes, reflecting the completeness of the knowledge base's records of logical changes.

[0065] Using verification rate and version evolution depth as inputs, a comprehensive knowledge health score is calculated by weighting them according to preset weights (e.g., verification rate accounts for 60%, version evolution depth accounts for 40%). This score comprehensively measures the accuracy and historical completeness of the knowledge base. When the comprehensive knowledge health score is lower than a preset health threshold, specific problems are further identified: for modules with low verification rates, nodes in the "pending confirmation" state are marked; for modules with insufficient version evolution depth, nodes that have been verified but lack historical version associations are marked. All marked low-health nodes trigger a unified review process, generating a review list and pushing it to the development or architect side, requiring manual intervention to check the accuracy and completeness of the logical node. Through the above dual quantitative evaluation of coverage and health, a visual measurement of knowledge assets is achieved, providing a clear data-driven basis for the continuous optimization of the knowledge base.

[0066] This step establishes a quantitative assessment system for knowledge assets. The system iterates through the total number of logical nodes in the knowledge base, calculates the knowledge coverage rate by combining it with the estimated total number of business logic nodes in the codebase, and marks low-coverage modules when the coverage rate is below a threshold, generating completion suggestions. Simultaneously, it calculates the percentage of verified nodes as the verification rate and the average number of versions as the evolution depth, and weights these factors to calculate a comprehensive knowledge health score. Nodes falling below a threshold are marked as unhealthy and trigger a review. This achieves digital measurement of knowledge assets, providing a data-driven basis for continuous optimization.

[0067] In the fintech sector, knowledge coverage and health assessments can be applied to compliance audit preparation and team performance management. For example, a payment institution needs to prove to regulators that its core anti-money laundering logic has been fully documented. The system calculates knowledge coverage (e.g., the captured logic accounts for 85% of all estimated business). If the coverage is below a threshold, the system automatically identifies the "cross-border remittance module" as a low-coverage area and generates supplementation suggestions, guiding the team to prioritize supplementing the rules for that module. Simultaneously, the system comprehensively scores the knowledge health of each business domain. If a module's health is below a threshold, it indicates insufficient verification or missing version history, triggering a review process and pushing the request to quality management personnel for manual review—for example, checking whether the "compliance reporting logic" has missed any abnormal branches. These indicators can also be used for performance evaluation: teams with high coverage and high health represent excellent knowledge management, while low-scoring teams require targeted training or additional review resources. By continuously tracking the trends in coverage and health, management can quantitatively assess technical debt, accurately allocate governance resources, and ensure that core knowledge assets remain in a high-quality state in the long term.

[0068] In one embodiment, a knowledge capture device based on RAG and business logic is provided, which corresponds one-to-one with the knowledge capture method based on RAG and business logic in the above embodiments. (Refer to...) Figure 7 , Figure 7 This is a schematic diagram of the functional modules of a preferred embodiment of the knowledge capture device based on RAG and business logic of the present invention. The modules include a trigger-based betting capture module 10, a double-blind cross-validation module 20, a reverse lookup conflict warning module 30, a tracking and storage module 40, and an intelligent question-answering module 50. Detailed descriptions of each functional module are as follows: Trigger the betting capture module 10, which is used to respond to code submission events, detect changed code and identify change patterns, generate function descriptions based on the change patterns, push a confirmation task carrying the function descriptions to the development end, and obtain the development end's response information to the confirmation task; The double-blind cross-validation module 20 is used to parse the business logic of the modified code, generate a first set of logical triples, parse the business logic of the function description based on the response information, generate a second set of logical triples, perform semantic equivalence comparison between the first set of logical triples and the second set of logical triples, and verify the consistency between the modified code and the function description based on the comparison results. The reverse lookup conflict warning module 30 is used to, after verification, perform equivalent association between the first set of logical triples and the second set of logical triples, and take at least one logical triple from the first set of logical triples and / or at least one logical triple from the second set of logical triples as knowledge to be added to the database. Based on the RAG retrieval enhancement generation mechanism, it performs multi-source retrieval on the knowledge to be added to the database, performs conflict determination on the multi-source retrieval results, and generates conflict determination results. The tracking storage module 40 is used to store the knowledge to be added to the multimodal knowledge base according to the conflict determination result. When storing, it queries the historical knowledge base to see if there is a historical version corresponding to the knowledge to be added. Based on the query result, it establishes a version association relationship between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. The intelligent question answering module 50 is used to respond to natural language questions by retrieving knowledge fragments related to the natural language questions from the updated multimodal knowledge base, inputting the relevant knowledge fragments as context into the large language model, and generating a response result.

[0069] In one embodiment, triggering the betting capture module 10 includes: Detect the changes to the files and code in the code commit event, and determine the changed code based on the changes to the files and code. The change code is parsed to identify the change pattern; Based on the context information of the modified code and the modification pattern, a natural language description is generated, and the natural language description is used as the initial functional description. The knowledge record confirmation task carrying the initial functional description will be pushed to the development end; Obtain the response information from the development end to the knowledge record confirmation task, and update the trust score of the development end based on the response information and historical response records.

[0070] In one embodiment, the double-blind cross-validation module 20 includes: The modified code is parsed to extract the conditional branch structure, loop structure, state transition node, exception handling node, and strategy selection node. A first set of logical triples is generated based on the conditional branching structure, loop structure, state transition node, exception handling node, and strategy selection node. Natural language semantic parsing is performed on the functional description to extract the business logic elements in the functional description; The business logic elements are semantically generalized by synonym replacement and word order adjustment, and a second set of logical triples is generated based on the processing results. Perform a semantic equivalence comparison between the first set of logical triples and the second set of logical triples; If the first set of logical triples is determined to be semantically equivalent to the second set of logical triples, then the functional description consistency verification passes. If the first set of logical triples is determined to be semantically inequivalent to the second set of logical triples, a verification conflict alarm is generated and returned to the development end.

[0071] In one embodiment, the reverse lookup conflict warning module 30 includes: Semantic vector retrieval is performed based on the natural language description of the knowledge to be added to the database; Based on the code structure of the knowledge to be added to the database, perform code structure feature retrieval; Based on the metadata of the code commit event, historical commit information retrieval is performed; Cross-validation was performed on the three search results, and the confidence scores of each search result were weighted and adjusted based on the cross-validation results. The search results are fused and sorted according to the weighted adjustment, and the matching type between the knowledge to be added to the database and the historical knowledge base is determined according to the fusion and sorting results and the cross-validation results. When the matching type of the knowledge to be added to the historical knowledge base is the same as that of the knowledge to be added, the knowledge to be added to the knowledge base is marked as known logic; When the matching type between the historical knowledge base and the knowledge to be added is logically similar but the conditions or actions are different, a conflict alarm and a comparison of old and new information are generated. When the matching type of the knowledge to be added in the historical knowledge base is not the same as that of the knowledge to be added, the knowledge to be added is marked as new logic. When the matching type between the historical knowledge base and the knowledge to be added to the database is logically contradictory, a contradiction alarm is generated.

[0072] In one embodiment, the tracking storage module 40 includes: When storing the knowledge to be added to the database, extract the logical identifier of the knowledge to be added to the database, and use the logical identifier as an index to query whether there are historical nodes with the same logical identifier in the historical knowledge base. When there are historical nodes with the same logical identifier, the knowledge to be added to the database is used as a new node to establish a parent-child relationship pointing to the historical node; When no historical node with the same logical identifier exists, the knowledge to be added to the database is marked as the root node; The changes to the knowledge to be added to the database are recorded and an evolution index is constructed to complete the update of the multimodal knowledge base.

[0073] In one embodiment, the tracking storage module 40 further includes: The code repository's historical commit records are used to crawl the full code or incrementally changed code, and the full code or incrementally changed code is compared between versions to obtain a list of changed files and information on changed lines of code. Based on the list of changed files and the information on changed lines of code, the full code or incremental changed code is converted into a structured intermediate representation; The structured intermediate representation is parsed to extract conditional branching logic, loop logic, data flow logic, business rule logic, and context association logic; Logical triples are generated based on the conditional branching logic, loop logic, data flow logic, business rule logic, and context association logic, and a confidence level is generated for each logical triple. Perform single-item consistency verification on the logical triples, store the verified logical triples in the multimodal knowledge base, and associate them with version tags and timestamp tags. Mark logical triples with confidence scores below a preset threshold as pending confirmation.

[0074] Specific limitations regarding the knowledge capture device based on RAG and business logic can be found in the aforementioned limitations of the knowledge capture method based on RAG and business logic, and will not be repeated here. Each module in the aforementioned knowledge capture device based on RAG and business logic can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0075] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a knowledge capture method based on RAG and business logic on the server side.

[0076] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 9As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a knowledge capture method based on RAG and business logic.

[0077] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: In response to a code commit event, the system detects changed code and identifies the change pattern, generates a functional description based on the change pattern, pushes a confirmation task carrying the functional description to the development end, and obtains the development end's response information to the confirmation task. The business logic of the modified code is parsed to generate a first set of logical triples. Based on the response information, the business logic of the function description is parsed to generate a second set of logical triples. The first set of logical triples and the second set of logical triples are semantically equivalent. The consistency between the modified code and the function description is verified based on the comparison results. After verification, the first set of logical triples and the second set of logical triples are equivalently associated, and at least one logical triple from the first set of logical triples and / or at least one logical triple from the second set of logical triples are taken as knowledge to be added to the database. Based on the RAG retrieval enhancement generation mechanism, multi-source retrieval is performed on the knowledge to be added to the database, and conflict determination is performed on the multi-source retrieval results to generate conflict determination results. Based on the conflict determination result, the knowledge to be added to the database is stored in the multimodal knowledge base. During storage, the database is queried to see if there is a historical version corresponding to the knowledge to be added. Based on the query result, a version association relationship is established between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. In response to a natural language question, knowledge fragments related to the natural language question are retrieved from the updated multimodal knowledge base, and the relevant knowledge fragments are used as context input to the large language model to generate a response.

[0078] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: In response to a code commit event, the system detects changed code and identifies the change pattern, generates a functional description based on the change pattern, pushes a confirmation task carrying the functional description to the development end, and obtains the development end's response information to the confirmation task. The business logic of the modified code is parsed to generate a first set of logical triples. Based on the response information, the business logic of the function description is parsed to generate a second set of logical triples. The first set of logical triples and the second set of logical triples are semantically equivalent. The consistency between the modified code and the function description is verified based on the comparison results. After verification, the first set of logical triples and the second set of logical triples are equivalently associated, and at least one logical triple from the first set of logical triples and / or at least one logical triple from the second set of logical triples are taken as knowledge to be added to the database. Based on the RAG retrieval enhancement generation mechanism, multi-source retrieval is performed on the knowledge to be added to the database, and conflict determination is performed on the multi-source retrieval results to generate conflict determination results. Based on the conflict determination result, the knowledge to be added to the database is stored in the multimodal knowledge base. During storage, the database is queried to see if there is a historical version corresponding to the knowledge to be added. Based on the query result, a version association relationship is established between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. In response to a natural language question, knowledge fragments related to the natural language question are retrieved from the updated multimodal knowledge base, and the relevant knowledge fragments are used as context input to the large language model to generate a response.

[0079] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0080] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0081] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0082] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0083] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A knowledge capture method based on RAG and business logic, characterized in that, Includes the following steps: In response to a code commit event, the system detects changed code and identifies the change pattern, generates a functional description based on the change pattern, pushes a confirmation task carrying the functional description to the development end, and obtains the development end's response information to the confirmation task. The business logic of the modified code is parsed to generate a first set of logical triples. Based on the response information, the business logic of the function description is parsed to generate a second set of logical triples. The first set of logical triples and the second set of logical triples are semantically equivalent. The consistency between the modified code and the function description is verified based on the comparison results. After verification, the first set of logical triples and the second set of logical triples are equivalently associated. At least one logical triple from the first set of logical triples and / or at least one logical triple from the second set of logical triples are taken as knowledge to be added to the database. Based on the RAG retrieval enhancement generation mechanism, multi-source retrieval is performed on the knowledge to be added to the database. The multi-source retrieval results are then used to determine conflicts and generate conflict determination results. Based on the conflict determination result, the knowledge to be added to the database is stored in the multimodal knowledge base. During storage, the database is queried to see if there is a historical version corresponding to the knowledge to be added. Based on the query result, a version association relationship is established between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. In response to a natural language question, knowledge fragments related to the natural language question are retrieved from the updated multimodal knowledge base, and the relevant knowledge fragments are used as context input to the large language model to generate a response.

2. The knowledge capture method based on RAG and business logic as described in claim 1, characterized in that, In response to a code commit event, the system detects changed code and identifies the change pattern. Based on the change pattern, it generates a functional description and pushes a confirmation task carrying the functional description to the development team. The system then obtains the development team's response information to the confirmation task, including: Detect the changes to the files and code in the code commit event, and determine the changed code based on the changes to the files and code. The change code is parsed to identify the change pattern; Based on the context information of the modified code and the modification pattern, a natural language description is generated, and the natural language description is used as the initial functional description. The knowledge record confirmation task carrying the initial functional description will be pushed to the development end; Obtain the response information from the development end to the knowledge record confirmation task, and update the trust score of the development end based on the response information and historical response records.

3. The knowledge capture method based on RAG and business logic as described in claim 1, characterized in that, Parse the business logic of the modified code to generate a first set of logical triples; based on the response information, parse the business logic of the function description to generate a second set of logical triples; perform a semantic equivalence comparison between the first set of logical triples and the second set of logical triples; and verify the consistency between the modified code and the function description based on the comparison results, including: The modified code is parsed to extract the conditional branch structure, loop structure, state transition node, exception handling node, and strategy selection node. A first set of logical triples is generated based on the conditional branching structure, loop structure, state transition node, exception handling node, and strategy selection node. Natural language semantic parsing is performed on the functional description to extract the business logic elements in the functional description; The business logic elements are semantically generalized by synonym replacement and word order adjustment, and a second set of logical triples is generated based on the processing results. Perform a semantic equivalence comparison between the first set of logical triples and the second set of logical triples; If the first set of logical triples is determined to be semantically equivalent to the second set of logical triples, then the functional description consistency verification passes. If the first set of logical triples is determined to be semantically inequivalent to the second set of logical triples, a verification conflict alarm is generated and returned to the development end.

4. The knowledge capture method based on RAG and business logic as described in claim 1, characterized in that, After successful verification, the first set of logical triples and the second set of logical triples are equivalently associated. At least one logical triple from the first set and / or at least one logical triple from the second set of logical triples are considered as knowledge to be added to the database. Based on the RAG retrieval enhancement generation mechanism, a multi-source retrieval is performed on the knowledge to be added to the database. Conflict determination is then performed on the multi-source retrieval results to generate conflict determination results, including: Semantic vector retrieval is performed based on the natural language description of the knowledge to be added to the database; Based on the code structure of the knowledge to be added to the database, perform code structure feature retrieval; Based on the metadata of the code commit event, historical commit information retrieval is performed; Cross-validation was performed on the three search results, and the confidence scores of each search result were weighted and adjusted based on the cross-validation results. The search results are fused and sorted according to the weighted adjustment, and the matching type between the knowledge to be added to the database and the historical knowledge base is determined according to the fusion and sorting results and the cross-validation results. When the matching type of the knowledge to be added to the historical knowledge base is the same as that of the knowledge to be added, the knowledge to be added to the knowledge base is marked as known logic; When the matching type between the historical knowledge base and the knowledge to be added is logically similar but the conditions or actions are different, a conflict alarm and a comparison of old and new information are generated. When the matching type of the knowledge to be added in the historical knowledge base is not the same as that of the knowledge to be added, the knowledge to be added is marked as new logic. When the matching type between the historical knowledge base and the knowledge to be added to the database is logically contradictory, a contradiction alarm is generated.

5. The knowledge capture method based on RAG and business logic as described in claim 1, characterized in that, Based on the conflict determination result, the knowledge to be added to the database is stored in a multimodal knowledge base. During storage, the database is queried to determine if a historical version corresponding to the knowledge to be added exists. Based on the query result, a version association relationship is established between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base, including: When storing the knowledge to be added to the database, extract the logical identifier of the knowledge to be added to the database, and use the logical identifier as an index to query whether there are historical nodes with the same logical identifier in the historical knowledge base. When there are historical nodes with the same logical identifier, the knowledge to be added to the database is used as a new node to establish a parent-child relationship pointing to the historical node; When no historical node with the same logical identifier exists, the knowledge to be added to the database is marked as the root node; The changes to the knowledge to be added to the database are recorded and an evolution index is constructed to complete the update of the multimodal knowledge base.

6. The knowledge capture method based on RAG and business logic as described in claim 1, characterized in that, Based on the conflict determination result, the knowledge to be added to the database is stored in a multimodal knowledge base. During storage, the database is queried to determine if a historical version corresponding to the knowledge to be added exists. Based on the query result, a version association relationship is established between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. The method also includes: The code repository's historical commit records are used to crawl the full code or incrementally changed code, and the full code or incrementally changed code is compared between versions to obtain a list of changed files and information on changed lines of code. Based on the list of changed files and the information on changed lines of code, the full code or incremental changed code is converted into a structured intermediate representation; The structured intermediate representation is parsed to extract conditional branching logic, loop logic, data flow logic, business rule logic, and context association logic; Logical triples are generated based on the conditional branching logic, loop logic, data flow logic, business rule logic, and context association logic, and a confidence level is generated for each logical triple. Perform single-item consistency verification on the logical triples, store the verified logical triples in the multimodal knowledge base, and associate them with version tags and timestamp tags. Mark logical triples with confidence scores below a preset threshold as pending confirmation.

7. The knowledge capture method based on RAG and business logic as described in any one of claims 1-6, characterized in that, The multi-dimensional quantitative evaluation of the multimodal knowledge base also includes: Traverse the total number of logical nodes stored in the multimodal knowledge base to obtain the estimated total number of business logic in the code library corresponding to the multimodal knowledge base; The ratio of the total number of logical nodes to the estimated total number of business logic nodes is used as the knowledge coverage rate. When the knowledge coverage rate is lower than a preset coverage threshold, low-coverage modules are marked and completion suggestions are generated. Traverse the stored logical nodes in the multimodal knowledge base, and count the number of verified nodes that have been verified and the number of historical versions associated with each logical node; The verification rate is calculated as the ratio of the number of verified nodes to the total number of logical nodes. Calculate the average number of historical versions as the version evolution depth; A comprehensive score for knowledge health is calculated based on the verification rate and the version evolution depth. When the overall health score of the knowledge is lower than the preset health threshold, the low health node is marked and the review process is triggered.

8. A knowledge capture device based on RAG and business logic, characterized in that, The knowledge capture device based on RAG and business logic includes: The betting capture module is triggered in response to code commit events, detects code changes and identifies change patterns, generates a function description based on the change pattern, pushes a confirmation task carrying the function description to the development end, and obtains the development end's response information to the confirmation task. The double-blind cross-validation module is used to parse the business logic of the modified code, generate a first set of logical triples, parse the business logic of the function description based on the response information, generate a second set of logical triples, perform semantic equivalence comparison between the first set of logical triples and the second set of logical triples, and verify the consistency between the modified code and the function description based on the comparison results. The reverse lookup conflict warning module is used to, after verification, equivalently associate the first set of logical triples with the second set of logical triples, and take at least one logical triple from the first set of logical triples and / or at least one logical triple from the second set of logical triples as knowledge to be added to the database. Based on the RAG retrieval enhancement generation mechanism, it performs multi-source retrieval on the knowledge to be added to the database, performs conflict determination on the multi-source retrieval results, and generates conflict determination results. The tracking storage module is used to store the knowledge to be added to the database into the multimodal knowledge base according to the conflict determination result. When storing, it queries the historical knowledge base to see if there is a historical version corresponding to the knowledge to be added. Based on the query result, it establishes a version association relationship between the knowledge to be added and the historical version to complete the update of the multimodal knowledge base. The intelligent question answering module is used to respond to natural language questions by retrieving knowledge fragments related to the natural language questions from the updated multimodal knowledge base, inputting the relevant knowledge fragments as context into the large language model, and generating a response result.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a knowledge capture program based on RAG and business logic stored in the memory and executable on the processor. When the knowledge capture program based on RAG and business logic is executed by the processor, it implements the steps of the knowledge capture method based on RAG and business logic as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a knowledge capture program based on RAG and business logic. When the knowledge capture program based on RAG and business logic is executed by the processor, it implements the steps of the knowledge capture method based on RAG and business logic as described in any one of claims 1-7.

Images