Knowledge management method and apparatus

Abstract

An embodiment of the present application provides a knowledge management method and device, comprising: obtaining structured definition information of a data object in a target database, extracting first type of summary information of the data object based on the structured definition information; obtaining a dependency relationship between code files in a target code library, determining at least one starting file from the target code library based on the dependency relationship, and performing traversal learning along the dependency relationship starting from the starting file to obtain second type of summary information of the target code library; detecting feedback information in an interaction process, and in response to the feedback information satisfying a preset condition, constructing or updating a mapping relationship between object identification and business terms based on the feedback information; and outputting knowledge data in response to a knowledge calling request based on the first type of summary information, the second type of summary information, and the mapping relationship. In this way, automatic acquisition and feedback self-evolution of knowledge are realized, and manual maintenance cost and Token overhead of model calling are reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to knowledge management methods and apparatus. Background Technology

[0002] Large language model intelligent agents typically rely on extensive domain knowledge when handling business problems, such as database table structures and business logic implementation methods. Related technologies usually provide knowledge to the model by manually writing knowledge documents or injecting all prompt words. When a user request is received, the system loads the corresponding document fragments or directly injects all knowledge into the context for the model to process.

[0003] However, when business processes iterate rapidly, the aforementioned technologies suffer from high manual maintenance costs and delayed updates, leading to models generating incorrect results based on outdated knowledge. The full injection method results in excessively large amounts of context data, causing huge token overhead for model calls, which increases the system's data processing pressure and memory resource consumption. At the same time, existing solutions lack systematic means of acquiring business logic from the codebase and lack the ability to automatically update knowledge based on interactive feedback, causing the system to repeatedly process the same erroneous requests, resulting in a waste of computing resources. The overall knowledge utilization and processing efficiency of the system need to be improved. Summary of the Invention

[0004] This application provides a knowledge management method, apparatus, electronic device, and computer-readable storage medium to at least partially solve the aforementioned problems existing in the related technologies.

[0005] According to one aspect of this application, a knowledge management method is provided, comprising: obtaining structured definition information of data objects in a target database, and extracting first-type summary information of the data objects based on the structured definition information; obtaining the dependency relationships between code files in a target code library, determining at least one starting file from the target code library based on the dependency relationships, and traversing and learning along the dependency relationships starting from the starting file to obtain second-type summary information of the target code library; detecting feedback information during the interaction process, and in response to the feedback information satisfying preset conditions, constructing or updating the mapping relationship between object identifiers and business terms based on the feedback information; and outputting knowledge data in response to a knowledge call request based on the first-type summary information, the second-type summary information, and the mapping relationship.

[0006] According to one aspect of this application, a knowledge management device is provided, comprising: a first acquisition module, configured to acquire structured definition information of data objects in a target database, and extract first type summary information of the data objects based on the structured definition information; a second acquisition module, configured to acquire dependency relationships between code files in a target code library, determine at least one starting file from the target code library based on the dependency relationships, and perform traversal learning along the dependency relationships starting from the starting file to obtain second type summary information of the target code library; a first response module, configured to detect feedback information during the interaction process, and construct or update the mapping relationship between object identifiers and business terms based on the feedback information in response to the feedback information meeting preset conditions; and a second response module, configured to output knowledge data in response to a knowledge call request based on the first type summary information, the second type summary information, and the mapping relationship.

[0007] According to one aspect of this application, an electronic device is provided, including a processor and a memory; the memory stores a computer program; when the processor executes the computer program, it implements any of the above-described knowledge management methods.

[0008] According to one aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements any of the above-described knowledge management methods.

[0009] One embodiment of this application provides a knowledge management method, comprising: acquiring structured definition information of data objects in a target database; extracting a first type of summary information of the data objects based on the structured definition information; acquiring the dependency relationships between code files in a target code library; determining at least one starting file from the target code library based on the dependency relationships; and traversing and learning along the dependency relationships starting from the starting file to obtain a second type of summary information of the target code library; detecting feedback information during the interaction process; and, in response to the feedback information meeting preset conditions, constructing or updating the mapping relationship between object identifiers and business terms based on the feedback information; and outputting knowledge data in response to a knowledge call request based on the first type of summary information, the second type of summary information, and the mapping relationship. This achieves automatic knowledge acquisition and self-evolution through feedback, reduces manual maintenance costs and token overhead for model calls, and improves the processing efficiency of knowledge management. Simultaneously, through layered loading and on-demand acquisition, it reduces the data processing pressure and memory resource consumption when the model processes context data, and reduces redundant computational resource waste caused by repeatedly processing erroneous requests. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic diagram of a system architecture is shown in one exemplary embodiment of this application; Figure 2 This application shows a flowchart of a method in one exemplary embodiment; Figure 3 A schematic diagram of a self-evolving knowledge management process in one exemplary embodiment of this application is shown; Figure 4 A schematic diagram of a code learner in one exemplary embodiment of this application is shown; Figure 5 This diagram illustrates a negative feedback self-learning closed loop in one exemplary embodiment of this application. Figure 6 This invention provides a diagram illustrating the apparatus composition in one exemplary embodiment of the present application. Figure 7 This illustration shows a schematic diagram of the structure of an electronic device according to one exemplary embodiment of the present application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0014] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0015] The method in one embodiment of this application can run on a terminal device or a server. The terminal device can be a local terminal device. When the method in the embodiment runs on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and client devices. Figure 1 The figure shows a cloud interaction system architecture diagram provided in this application. As shown, the cloud interaction system may include: a client device 10 and a server 20, wherein the client device 10 can be connected to the server 20 via a network 30.

[0016] It should be noted that the information (including but not limited to user input information, such as information entered by the user into an input box), data (including but not limited to data used for analysis, stored data, and displayed data, such as context code, all code of the current project, service pressure corresponding to operations performed on all code of the current project, and code development status of the current project), and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the context code, operations performed on all code of the current project, and the service pressure and code development status involved in the operations in the embodiments of this application are all obtained under full authorization.

[0017] A knowledge management method according to one embodiment of this application, such as Figure 2 As shown, the method may include: Step S210: Obtain the structured definition information of data objects in the target database, and extract the first type of summary information of the data objects based on the structured definition information; Step S230: Obtain the dependency relationships between code files in the target code library, determine at least one starting file from the target code library based on the dependency relationships, and traverse and learn along the dependency relationships starting from the starting file to obtain the second type of summary information of the target code library; Step S250: Detect feedback information during the interaction process; in response to feedback information meeting preset conditions, construct or update the mapping relationship between object identifiers and business terms based on the feedback information. Step S270: Based on the first type of summary information, the second type of summary information, and the mapping relationship, output knowledge data in response to the knowledge call request.

[0018] According to one embodiment of this application, automatic knowledge acquisition and feedback self-evolution are achieved, reducing manual maintenance costs and token overhead for model calls, and improving the processing efficiency of knowledge management. Simultaneously, through layered loading and on-demand acquisition, the data processing pressure and memory resource consumption when the model processes context data are reduced, and redundant computing resource waste caused by repeatedly processing erroneous requests is minimized.

[0019] like Figure 3 The diagram illustrates a self-evolving knowledge management process. On the left are three learner modules: an offline learner (scanning database tables → LLM extracting summaries → categorizing into business domains, blue), a code learner (building a dependency graph → learning along the entry chain → semantic chunk storage, green), and a negative feedback self-learning module (Agent answers incorrectly → user corrects → extracts business keywords → writes back alias indexes, purple). All three write data to the intermediate knowledge base. The middle section shows the hierarchical structure of the knowledge base: L0 business domain index (approximately 200 tokens per load), L1 table summary + terminology mapping (approximately 500 tokens per hit domain load), and L2 complete table structure + code context (obtained on demand). It also displays knowledge accumulation statistics (7,760 terms, 5,997 code blocks, 48 ​​skills, 10,982 Q&A records) and three-layer persistence (vector database, file persistence, code repository, cache synchronization); three-layer progressive loading, approximately 700 tokens per request, second-level reconstruction after container migration, and real-time knowledge synchronization across nodes. On the right is the Agent interaction process: answering user questions → incorrect answers trigger negative feedback learning → knowledge flywheel "becomes more accurate with use".

[0020] The embodiments of this application will be further described below.

[0021] In step S210, the structured definition information of data objects in the target database is obtained, and the first type of summary information of the data objects is extracted based on the structured definition information. In this way, by automatically obtaining the structured definition information of data objects and extracting summaries, the high cost of manually writing explanatory documents for each object is avoided, achieving automated parsing and full coverage of database knowledge, and significantly improving the timeliness and accuracy of knowledge acquisition.

[0022] In one implementation, the system initiates an asynchronous background task to scan all tables in the database instance specified in the configuration. For each table, the complete DDL (Data Definition Language) definition statement is obtained by executing the "SHOW CREATE TABLE" statement. The DDL text is then input into a large language model, which extracts structured summary information from the DDL, including the table's Chinese purpose description, key fields and their Chinese business meanings, a table of enumerated field values ​​and meanings, and typical business query SQL examples. For example, for a table named "Guess_Activity," the summary extracted by the large language model includes a purpose description of the "Guessing Game Activity Main Table," the meaning of the field "gameName=Activity Name," an enumeration comparison of the "status field: ACTIVE=In Progress, ENDED=Ended," and a sample SQL statement for querying records by activity name.

[0023] Optionally, the structured definition information includes data definition statements for data objects, which describe the structure, fields, and constraints of the data objects.

[0024] Optionally, structured definition information can take the form of DDL (Data Definition Language) statements, metadata descriptions of database tables, or table structure definitions obtained through database system view queries. Considering the differences in how different types of database systems obtain structured definition information, as a possible implementation, for relational databases, the complete DDL text can be obtained by executing the SHOW CREATE TABLE statement; for non-relational databases or data warehouses, the structure definition of the collection can be obtained by querying system directory tables or metadata interfaces. It should be noted that in addition to basic structural information such as field names, field types, and primary / foreign key constraints, structured definition information can also include other information, such as default values ​​for fields, index definitions, and comment information. This extended information can further assist the language model in more accurately understanding the business semantics of data objects. The above description of the sources and composition of structured definition information is only one example; in actual implementation, it can be flexibly configured according to the database type and business requirements.

[0025] Optionally, the first type of summary information includes a description of the purpose of the data object, the meaning of key fields, a comparison of enumerated values, and a query example.

[0026] Optionally, the first type of summary information can be one or more combinations of structured information such as a Chinese description of the table's purpose, key fields and their Chinese business meanings, a table of values ​​and meanings for enumerated type fields, and SQL examples of typical business queries. One objective of this embodiment is to reduce the human cost of manually writing table description documents by submitting structured definition information to a language model for semantic extraction. Furthermore, it allows the summary information to have a unified format, facilitating subsequent classification and archiving by business domain. Besides automatically extracting the first type of summary information through the language model, it can also receive manually supplemented notes or import partial summary content from an existing data dictionary; this application is not limited to these methods. In addition to basic business descriptions, the first type of summary information can also include other information, such as descriptions of relationships between tables and extended information like field data distribution characteristics. This extended information can further enrich the content dimensions of the knowledge base and improve the accuracy of subsequent knowledge retrieval and injection.

[0027] In an optional implementation, the structured definition information of data objects in the target database is obtained, and a first type of summary information of the data objects is extracted based on the structured definition information. This includes: scanning the target database to obtain the data definition statements of the data objects; submitting the data definition statements to a language model, and having the language model extract the first type of summary information of the data objects. This achieves automated extraction of structured definition information from the database, eliminating the need for manual documentation, effectively reducing the human cost of knowledge acquisition and improving knowledge coverage.

[0028] In one implementation, the system initiates a background asynchronous task to scan the configured database instance, executes the "SHOW CREATE TABLE" statement on each data table to obtain the DDL text, and then submits the DDL text in batches to the large language model, which extracts structured summary information such as the Chinese usage description of the table, the meaning of key fields, and the enumeration value comparison.

[0029] Optionally, data definition statements are used to describe the structure of data objects, which may include table column definitions, constraints, and index information. Optionally, data definition statements can be Data Definition Language (DDL) statements, such as the complete table structure definition text obtained by executing the "SHOW CREATE TABLE" statement. This data definition statement not only includes basic structural information such as field names and data types, but may also include extended information such as primary key constraints, foreign key relationships, default values, and comments. It should be noted that the specific form of data definition statements described above is only one example and is not intended to be limiting. In actual implementation, data definition statements can also be creation or modification statements for other types of data objects such as views and stored procedures, as long as they can be parsed and understood by the language model to understand their structured characteristics. Considering that different database systems may use different dialects or syntax rules, the method of obtaining data definition statements can also be adaptively adjusted according to the specific database type, thereby ensuring the completeness and accuracy of the structured definition information.

[0030] Optionally, a language model is used to perform semantic understanding and information extraction on structured definition information to generate structured summary content.

[0031] Optionally, the language model can be a large language model (LLM) with powerful natural language understanding and generation capabilities. After the acquired data definition statements are submitted to the language model, the language model can interpret the tedious code-based definitions based on its internal semantic knowledge base, extracting structured summary information such as the Chinese usage description of the table, key fields and their Chinese business meanings, a table of values ​​and meanings of enumerated fields, and typical business query examples. To avoid timeouts or context overflows caused by submitting too much data at once, a batch submission method can be used to package and send the data definition statements of multiple tables to the language model. In addition to requesting the remote language model service through API calls, language model instances can also be deployed locally for offline inference; this application is not limited to this. Through the automated extraction of the language model, the machine-readable low-level structure can be transformed into a business-readable high-level summary, greatly reducing the cost of manual sorting.

[0032] Optionally, scanning the target database is used to discover and collect the structured definition information of data objects, which can be performed in full or incremental mode. Optionally, scanning the target database can be a process of traversing all database instances specified in the configuration through a background asynchronous task, obtaining a list of all data tables and querying their structured definition information one by one. In one specific approach, the system can periodically trigger a full scan task to comprehensively grasp the latest structural state of the database. To improve scanning efficiency and reduce the performance impact on the production database, the scan operation can be configured to be executed during off-peak business hours, or access a read-only copy through a read-write separation mechanism. Furthermore, in addition to full scans, scanning the target database can also include listening to the target database's change log stream, obtaining the structured definition information of data objects based on data definition statement change events in the change log stream, thereby achieving incremental updates to the target database. This incremental scanning mechanism can promptly capture changes and trigger subsequent summary extraction processes when table structures undergo changes such as adding fields, modifying enumeration values, or discarding old tables, ensuring that the information in the knowledge base remains highly synchronized with the actual business database and avoiding the generation of erroneous instructions based on outdated structures.

[0033] In an optional implementation, scanning the target database includes: listening to the change log stream of the target database, and obtaining the structured definition information of data objects based on data definition statement change events in the change log stream, so as to achieve incremental updates to the target database. In this way, by capturing data definition statement change events through listening to the change log stream, the latest structured definition information can be obtained without a full, repeated scan, achieving incremental updates to the target database, effectively reducing system resource overhead and ensuring the real-time nature of knowledge synchronization.

[0034] In one implementation, when the business development team performs a field addition operation on the core order table of the transaction domain, the database system writes the change record to the change log stream. The monitoring component consumes this log entry in real time, parses it to identify the data object involved as the "Trade_Order" table and the change type as field addition, then retrieves the latest structured definition information of the table and submits it to the language model to re-extract the summary. Only the knowledge entries for this table are refreshed, without rescanning thousands of tables across the entire database. Specifically, the monitoring component uses pattern matching to extract table names and change types when parsing the logs. Log entries with abnormal formats are recorded in a queue awaiting manual verification to avoid missing critical changes.

[0035] Optionally, the change log stream is used to continuously capture structural change records in the target database, and it can include binary logs, transaction logs, or change data capture streams. The change log stream can be in various forms, such as binary logs, transaction log streams, or change data capture streams provided by the database system. The change log stream can be deployed on the database master node, or it can be set on a read-only replica or a separate log service node; this application is not limited to a specific deployment location. Considering that a full scan of the database table structure will generate significant input / output overhead and potential lock contention risks, listening to the change log stream can continuously capture structural changes in a non-intrusive manner, avoiding interference with normal database read / write operations. As one possible implementation, the consumption of the change log stream can be continuously subscribed and pushed using a real-time stream processing framework, or incremental logs can be periodically pulled using a timed polling method, depending on the business's timeliness requirements and system resource budget. It should be noted that the change log streams provided by different database systems differ in format and protocol. For example, some databases output change payloads in structured text format, while others record them in plain text statement format. This application is not limited to a specific log format, as long as the structural change content can be identified from it. At the exception handling level, when the change log stream experiences a consumption delay or interruption, the listening component can record the breakpoint and resume consumption from that point after recovery, ensuring that change events are not lost.

[0036] Optionally, data definition statement change events are used to identify changes to the data object structure, and may include event types such as table creation, table modification, or field modification. Optionally, data definition statement change events may include various types such as table creation events, table structure modification events, table deletion events, field addition events, field type change events, and index change events. As one possible implementation, data definition statement change events are parsed from the change log stream, and the information they carry includes at least the change operation type and the identifier of the affected data object. To avoid missing change events due to log format differences or parsing anomalies, the above method can use a combination of pattern matching and regular expression extraction to identify change content when parsing the change log stream. For log entries that cannot be automatically identified, further verification can be performed using an auxiliary verification mechanism; this application embodiment does not limit this. It should be noted that the parsing granularity of data definition statement change events can be adjusted according to actual needs, and can be accurate to changes at the single field level or only identify overall changes at the table level. In one specific approach, when a change event is parsed that involves a table structure modification, the system locates the corresponding data object entry in the knowledge base based on the table name carried in the event, triggering the process of re-acquiring the structured definition information and re-extracting the summary of that entry. For table deletion events, the corresponding knowledge entry can be marked as obsolete instead of being deleted immediately, in order to support possible subsequent recovery operations.

[0037] Optionally, incremental updates are used to refresh knowledge only on data objects that have changed, avoiding repeated scanning and learning of the entire database. Alternatively, incremental updates aim to re-extract and refresh knowledge only on data objects that have changed, rather than repeatedly scanning and relearning the entire database. Considering the uneven frequency of database table structure changes in enterprise business systems—some core transaction tables may change multiple times daily, while many historical tables remain stable for a long time—the incremental update mechanism allows the system to accurately allocate computing resources to data objects that have actually changed. This reduces the number of language model calls and token consumption, and also shortens the response latency of knowledge updates. Furthermore, incremental updates can incorporate a version marking mechanism during execution, recording a timestamp or sequence number for each update operation, allowing for backtracking and retrying in case of update failure. Similarly, for the same data object that changes multiple times in a short period, incremental updates can adopt a merging strategy, retaining only the latest version's structured definition information for submission, avoiding redundant information from repeatedly calling the language model to process intermediate states. As mentioned earlier, incremental updates and full scans are not mutually exclusive. The system can perform a full scan to establish a baseline knowledge base during the initial deployment, and then continuously rely on incremental updates to maintain the timeliness of the knowledge. When data inconsistency is detected, a full verification is triggered as a fallback measure.

[0038] In step S230, the dependency relationships between code files in the target code repository are obtained. Based on these dependencies, at least one starting file is determined from the target code repository, and learning is performed along the dependency relationships starting from the starting file to obtain the second type of summary information of the target code repository. In this way, by determining the starting file through dependency relationships and performing traversal learning from the starting file, the code logic of the complete business chain can be systematically learned, avoiding the context loss caused by learning individual files piecemeal, and effectively reducing unnecessary language model call overhead. In one implementation, a code repository containing a transaction service module is used as an example: The system first pulls the complete directory tree of the repository, parses the import statements in each source file, and constructs a directed dependency graph between files. Then, the system uses a preset entry class name suffix (such as...) to... The controller identifies seed files such as "OrderController" as starting files. Then, starting from "OrderController", it performs a breadth-first search along the dependency graph, visiting files such as OrderService, OrderDAO, and OrderEntity in sequence. For each file, it calls the language model to extract a functional summary, ultimately forming a second type of summary information for a complete order processing chain.

[0039] Optionally, dependencies are used to characterize the reference call relationships between code files. They are constructed by parsing the reference declarations in the code files, providing a path basis for traversal learning.

[0040] Optionally, dependencies can take the form of a directed dependency graph, where nodes represent code files and edges represent references between code files. Specifically, the system parses import statements or reference declarations in each code file using regular expressions, collecting declaration information in the form of "import com.xxx.xxx.ClassName", and constructs a directed dependency graph based on these reference declarations. Simultaneously, the system can also construct an inverted index from class names to file paths to support fast lookups. It should be noted that the dependency construction process is entirely completed locally, without involving language model calls, thus achieving zero-overhead static analysis. Besides constructing dependencies through import statements, the dependency graph can also be supplemented by parsing method call statements, class inheritance relationships, or interface implementation relationships in code files. Considering the possibility of circular dependencies in the code repository, the system can perform deduplication and cycle detection during dependency graph construction to ensure the correctness of subsequent traversal learning.

[0041] Optionally, the starting point file serves as the initial node for traversal learning. It is determined from the code files based on a preset starting point identifier, which includes an entry class name suffix and / or entry annotations. Alternatively, the starting point file can be the entry point file for a business function, identified by the preset starting point identifier. Specifically, the starting point identifier may include an entry class name suffix, such as... Controller Resource Endpoints are used to mark the entry point of an HTTP API. Consumer Listener is used to mark the message consumption entry point. Job Task Scheduler is used to mark the entry point for scheduled tasks. Handler is used to mark the entry point for event handling. When the source file has annotation information, the starting point identifier can also include entry point annotations, such as @Controller, @RestController, @KafkaListener, @Scheduled, etc. One objective of this embodiment is to identify the starting point file by using the entry class name suffix and / or entry point annotation, thereby accurately locating the entry point of the business function. This allows for subsequent learning to be organized at the granularity of "functional units," avoiding the high-cost scanning of calling the language model one by one in all code files. It should be noted that the above list of starting point identifiers is only an example and can be extended or customized according to business needs. This application does not intend to limit the specific form of the starting point identifier.

[0042] Optionally, traversal learning is used to search and traverse along the dependency relationship starting from the starting file, and extract functional summaries from the searched code files to learn the complete code logic of a business chain.

[0043] Optionally, traversal learning can be a breadth-first search (BFS) process along the directed dependency graph, starting from a starting file. Specifically, for each file accessed by BFS, the system reads its source code and calls the language model to generate a functional summary of that file. The summary includes information such as the file's role, key classes and methods, downstream dependencies, and data entities being operated on. Traversal learning is organized by "functional unit"—from the Controller method entry point to the Service layer, then to the DAO layer, and finally to the Entity object; the completion of learning all files along the entire chain is considered the completion of a complete functional unit. During traversal learning, when a node's reference declaration involves an external codebase, the system automatically adds that external codebase to the learning queue, initiating cross-repository chained learning. Simultaneously, preset diffusion constraints (such as a maximum number of followed repositories) control the learning scope to prevent unlimited diffusion. Considering that some code files may be accessed repeatedly through the search paths of multiple starting files, the system can maintain a set of accessed files for deduplication, avoiding resource waste caused by repeated calls to the language model.

[0044] Optionally, the second type of summary information is used to characterize the functional description of the code file. It is obtained by extracting the functional summary of the code file searched during the traversal learning process and storing it in blocks according to semantic boundaries.

[0045] Optionally, the second type of summary information may include the responsibility positioning of the code file, key classes and methods, downstream dependencies of calls, and data entities operated on. Specifically, the second type of summary information is processed into blocks at the semantic boundaries of the Abstract Syntax Tree (AST). For example, the summary of a class is one block, the summary of a method is one block, and the definition and comments of an enumeration type are one block. Each block carries its source file path information. These block-based summary information are encoded into semantic vectors through a vectorization model and stored in a vector database. At the same time, they are written in JSONL format to local files classified by business domain and synchronously pushed to a remote code repository for persistent backup. It should be noted that the granularity of the second type of summary information can be adjusted according to actual needs. In addition to splitting by class, method, and enumeration, it can also be split by code line count thresholds or functional module boundaries. This application does not limit this. Considering the differences in code complexity across different business domains, the level of detail in the summary information can also be dynamically adjusted according to the importance of the file and the frequency of calls.

[0046] In an optional implementation, the dependencies between code files in the target code library are obtained, including: parsing reference declarations in the code files and constructing a directed dependency graph based on the reference declarations; wherein, nodes in the directed dependency graph represent code files, and edges in the directed dependency graph represent reference relationships between code files. In this way, by constructing a directed dependency graph through parsing reference declarations in the code files, the analysis of dependencies between code files can be completed without calling a large language model, significantly reducing the resource overhead of code knowledge learning, while providing a structured navigation foundation for subsequent traversal learning.

[0047] In one implementation, a microservice code repository containing hundreds of Java source files is used as an example: The system first pulls the complete directory tree structure through the code repository's API, traversing all source files with the .java extension. For each source file, a predefined regular expression pattern is used to match the import statements, for example, extracting the referenced class name OrderService from "import com.example.trade.service.OrderService". Based on a pre-built inverted index from class name to file path, OrderService is located to the specific path of its definition file, and then a directed edge is established between the referencing file and the referenced file. After all the import statements in all files have been parsed, a directed dependency graph covering the entire code repository is formed, where each node represents a Java file and each directed edge represents an import reference relationship. This construction process is executed entirely locally without calling any large language model, thus completing the establishment of the code dependency topology with zero model overhead.

[0048] Optionally, reference declarations are used to declare dependencies between code files, and can take various forms, including but not limited to import statements or include directives. Optionally, a reference declaration can be a declaration statement in a code file used to import external classes, modules, or resources, and its specific form varies depending on the programming language. In Java, a reference declaration can be an import statement, such as "import com.example.xxx.xxx.ClassName"; in C++, it can be an include preprocessor directive; in Python, it can be an import statement or a from import statement; and in C#, it can be a using statement. Reference declarations can be parsed using two methods: regular expression matching and Abstract Syntax Tree (AST) parsing. Regular expression matching extracts reference declarations from the source file text using predefined pattern rules, offering fast processing speed and requiring no compilation environment support, making it suitable for rapid scanning of large-scale code repositories. AST parsing, on the other hand, uses a language parser to transform the source code into a structured syntax tree and then extracts the reference nodes from it, enabling more precise handling of complex syntax scenarios. Given the large number of files in the code repository and the fixed syntax of reference declarations, extracting reference declarations using local static parsing can identify dependencies without invoking a large language model, thus achieving dependency graph construction with zero model overhead. It should be noted that the above description of the specific form of reference declarations is merely an example, and this application does not intend to limit the language type or parsing method of reference declarations.

[0049] Optionally, a directed dependency graph is used to represent the reference relationships between code files, where nodes correspond to code files and directed edges correspond to the reference relationships between files.

[0050] Optionally, a directed dependency graph is a data structure that uses code files as nodes and the reference relationships between files as directed edges to depict the dependency topology within a code repository. During construction, the system traverses all source files in the directory tree, parses the reference declarations of each file, records the path information of the referenced files, and then converts each reference relationship into a directed edge in the graph. For example, when file A contains a reference declaration pointing to file B, an edge from node A to node B is generated in the directed dependency graph. Directed dependency graphs can be stored using adjacency lists, adjacency matrices, or edge sets. Adjacency lists have lower space overhead in sparse graph scenarios and are suitable for the storage needs of large-scale code repositories. While constructing the directed dependency graph, the system can also build an inverted index from class names to file paths, enabling quick location of the definition file when the class name is known, thereby accelerating file lookup during subsequent traversal and learning. The construction process of the directed dependency graph is entirely executed locally and does not involve any large language model calls. Therefore, the construction cost is linearly related to the number of files in the code repository, rather than being linked to the token consumption of model calls.

[0051] Optionally, in addition to recording basic inter-file reference relationships, the directed dependency graph can further carry edge type annotation information to distinguish reference relationships of different natures. For example, edges can be labeled as "inheritance reference" (such as a subclass referencing a parent class), "method call reference" (such as a Service layer calling a DAO layer method), "field reference" (such as referencing a constant field defined in another class), etc., so that subsequent traversal learning can select different summary extraction strategies based on the edge type. In another implementation, the edges in the directed dependency graph can also carry weight information. The weight can be assigned according to the frequency of reference or the importance of the reference type, so that high-weight dependency paths are visited first during breadth-first search (BFS). If a circular dependency occurs, that is, if a node is detected to have been visited during traversal, the system can avoid duplicate processing by maintaining a set of visited nodes, ensuring that the traversal process can terminate normally. It should be understood that the specific construction granularity and additional attributes of the directed dependency graph can be flexibly configured according to the business scenario and learning objectives, and this application embodiment does not limit this.

[0052] In an optional implementation, at least one starting file is determined from the target codebase based on dependencies, including: determining the starting file from the code files based on a preset starting point identifier; wherein the starting point identifier includes an entry class name suffix and / or an entry annotation. In this way, by automatically identifying the entry file of the business function as the starting point based on the preset starting point identifier, the starting position of code learning can be accurately located. This allows subsequent traversal learning to be organized at the granularity of the complete functional chain, avoiding the high-cost scanning of calling the language model one by one for all code files, and effectively reducing the resource overhead of code knowledge learning.

[0053] In one implementation, the system initiates an asynchronous background task to scan all database instances specified in the configuration. For each table, the complete data definition statement (DDL) is obtained by executing the "SHOW CREATE TABLE" statement. For example, for a transaction order table named "Trade_Order", the system obtains its DDL text and submits it in batches to the large language model. The large language model extracts the following structured information from the DDL: a Chinese description of the table's purpose (e.g., "Transaction Order Main Table"), key fields and their Chinese business meanings (e.g., "orderStatus=Order Status"), a table of values ​​and meanings for enumerated fields (e.g., "status field: ACTIVE=In Progress, ENDED=Completed"), and typical business query SQL (Structured Query Language) examples. After each batch of tables is learned, a checkpoint archive is saved, recording the learned tables, failed tables, and tables to be learned, so that learning can resume from a breakpoint after an interruption.

[0054] Optionally, data definition statements may include, but are not limited to, table creation statements, modification statements, or view definition statements, which are dynamically determined based on the database type.

[0055] Optionally, data definition statements can be declarative text used to describe the structure of data objects in a database, and their forms include, but are not limited to, CREATE TABLE, ALTER TABLE, and CREATE VIEW statements. In relational databases, data definition statements are typically obtained by executing specific query commands. For example, the "SHOW CREATE TABLE" statement retrieves the complete table creation statement, which includes rich structured metadata such as table name, field names, field types, primary key constraints, index definitions, and comment information. It should be noted that the above description of the specific forms of data definition statements is only one example. In actual implementation, the methods and syntax for obtaining data definition statements may differ for different types of database systems, and this application does not intend to limit this. In addition, besides containing basic structural definitions, data definition statements can also carry extended information such as foreign key relationships, partitioning strategies, and character set configurations. This extended information can further assist the language model in more accurately understanding the relationships and business semantics between data objects, thereby improving the quality and depth of summary extraction.

[0056] Optionally, the language model is used to receive data definition statements and extract structured summary information, including business purpose descriptions, field meanings, and enumeration mappings.

[0057] Optionally, the language model can be a large-scale pre-trained model with natural language understanding and generation capabilities, which receives data definition statements as input and outputs structured summary information. Considering the high cost and delayed updates of manually writing table description documents, as a possible implementation, data definition statements are submitted to the language model in batches, which automatically extracts structured information such as the Chinese usage description of the table, key fields and their Chinese business meanings, the value and meaning comparison of enumerated type fields, and SQL examples of typical queries. The specific type of language model can be flexibly selected according to the actual application scenario. For example, a general conversational large language model can be used, or a dedicated model fine-tuned for code and database domains can be used. It should be noted that the scale of batch submission can be dynamically configured according to the context window length and concurrent processing capability of the language model. By default, several tables' DDL texts are submitted in each batch to achieve a balance between call efficiency and token consumption. One objective of this embodiment is that by automatically extracting summaries through the language model, the lag of manual maintenance can be eliminated on the one hand, and the complete coverage of the entire database table structure knowledge can be achieved on the other hand.

[0058] Optionally, scanning the target database aims to traverse all data objects in the database instance through a background asynchronous task to obtain its underlying structure definition. Alternatively, scanning the target database can be executed automatically through a background asynchronous task, traversing one or more database instances specified in the configuration and obtaining the structured definition information of all data tables in each instance. Considering the large and continuously growing number of data tables in enterprise business systems, the scanning process can adopt a batch processing strategy. After each batch of tables is learned, a checkpoint archive file is saved, recording the list of tables that have been learned, the names and reasons for failed learning, and the list of tables to be processed. When the learning process is interrupted due to external reasons such as container restarts, the checkpoint file is automatically checked when the new service node starts, skipping completed tables and continuing to learn unfinished tables, avoiding wasting completed language model calls. It should be noted that the scanning can be triggered periodically or incrementally after listening to the database change log stream; this application is not limited to this. The scanning scope can be flexibly configured according to business needs, allowing for a complete scan of the entire database or scanning only a set of tables within a specified business domain or prefix, thus achieving a flexible balance between scanning efficiency and knowledge completeness.

[0059] In an optional implementation, the second type of summary information of the target code library is obtained by traversing and learning along the dependency relationship starting from the starting file. This further includes: performing a breadth-first search along the directed dependency graph starting from the starting file, and extracting functional summaries from the searched code files to obtain the second type of summary information of the target code library. Thus, performing a breadth-first search along the directed dependency graph starting from the starting file allows for systematic learning of code logic at the granular level of complete functional links, avoiding the context fragmentation problem caused by fragmented learning file by file. It also effectively reduces the number of language model calls, improving the efficiency and completeness of code knowledge extraction.

[0060] In one implementation, taking an e-commerce transaction microservice project as an example, the system starts from the seed file TradeController (the transaction controller, the HTTP interface entry point) and performs a breadth-first search along the directed dependency graph. First, it visits the TradeController node to extract a summary of its HTTP request handling functionality; then, it searches along the dependency edges to find the TradeService (transaction service layer) file it calls, and continues to extract a summary of its business logic; further, it searches to find TradeDAO (transaction data access layer) and TradeEntity (transaction entity class), extracting summaries of persistence operations and data mappings respectively. This entire process forms a complete call chain learning unit from the interface entry point to the data entity. Furthermore, if TradeService references utility classes from a public repository during the breadth-first search, the system will automatically add that external repository to the learning queue, achieving cross-repository chain tracing, while preventing the learning scope from expanding indefinitely by limiting the maximum number of repositories to be tracked.

[0061] Optionally, breadth-first search is used to traverse the directed dependency graph layer by layer from the starting file, extracting code knowledge in units of complete functional links.

[0062] Optionally, the breadth-first search traversal process starts with the root file and expands outwards layer by layer along the edges of the directed dependency graph. Specifically, starting from the Controller (HTTP interface entry point) method, the first layer visits the Service (business service layer) files it directly calls; the second layer visits the DAO (data access layer) files called by the Service layer; and the third layer visits the Entity (data entity) files operated on by the DAO layer. A complete functional unit is considered learned only after all files along the entire chain have been learned. It should be noted that the traversal depth of the breadth-first search can be configured according to the complexity of the business chain. It can be set to a fixed upper limit to control the learning scope and language model call cost, or it can be set to an unlimited depth to cover the entire call chain. During the traversal, each visited file node is marked as visited, avoiding repeated learning and repeated calls to the language model for the same file, thus effectively controlling Token (lexicon, language model billing unit) consumption. Furthermore, when encountering a circular dependency structure during traversal, the visited marking mechanism can also prevent infinite loops and ensure the normal termination of the traversal process.

[0063] Optionally, in addition to the standard breadth-first search strategy, other graph traversal strategies can be selected based on the architectural characteristics of the code repository. As one possible implementation, when the target code repository adopts an event-driven architecture and files are asynchronously decoupled via message queues, a depth-first search strategy can be used. This involves tracing deep along a single message processing link to the underlying entity before backtracking to explore other branches, better aligning with the business logic flow in an event-driven scenario. Another implementation can be to prioritize nodes based on their in-degree information in the directed dependency graph, prioritizing access to core common files that are depended upon by multiple upstream files, ensuring that knowledge of critical infrastructure code is extracted first. It should be understood that the choice of traversal strategy depends on the actual architectural characteristics of the code repository and the learning objectives. Each of the above strategies has its advantages and disadvantages, and this application does not limit its application. Those skilled in the art can flexibly choose or combine strategies according to specific application scenarios.

[0064] Optionally, functional summary extraction is used to generate structured functional description information for each code file found through the traversal search, as a component of the second type of summary information. Optionally, functional summary extraction involves submitting the source code content of the searched code files to a language model, which analyzes and generates structured summary information for that file. Summary information includes, but is not limited to: the file's role (e.g., "responsible for creating transaction orders and managing state transitions"), key class and method names and their functional descriptions, a list of downstream dependent files called, the data entities operated on, and their corresponding database table mapping relationships. It should be noted that the granularity and content dimensions of functional summary extraction can be flexibly adjusted according to the application scenario of the knowledge base. For example, for data access layer files, the summary can focus on the structured query language operation types and the data tables involved; for business logic layer files, the summary can focus on business rules and state machine transition logic. The extracted summary information is processed in blocks at the granularity of AST (Abstract Syntax Tree, a structured representation of source code) semantic boundaries. Each block carries source file path information, facilitating subsequent semantic retrieval and knowledge tracing. One objective of this embodiment is to transform unstructured source code into structured knowledge entries through functional summary extraction. This reduces the complexity of knowledge storage and retrieval on the one hand, and enables the language model to perform reasoning based on refined summaries rather than complete source code on the other hand, significantly reducing the lexical overhead of context injection.

[0065] In an optional implementation, the breadth-first search along the directed dependency graph further includes: when the reference declaration of a searched code file involves an external code library, adding the external code library to a learning queue; and controlling the learning queue based on preset diffusion constraints to achieve chained learning of the external code library. In this way, when the reference declaration of a searched code file involves an external code library, the external code library is automatically added to the learning queue, and the scope is controlled by diffusion constraints. This ensures the integrity of the business call chain knowledge on the one hand, and effectively prevents the unlimited spread of the learning scope on the other, achieving systematic chained learning of cross-repository code knowledge on the other.

[0066] In one implementation, taking a content transaction microservice project as an example: the system starts from a Controller seed file of the project and performs Breadth-First Search (BFS) traversal along the directed dependency graph. When traversing a Service layer file, parsing its import statement reveals a reference to a utility class from the "Content Common Component Library." The system determines that this reference involves an external code library and adds the "Content Common Component Library" to the learning queue. In another implementation, if a DAO layer file is found to have an import statement referencing an entity class from the "User Basic Service Library," the system similarly adds the "User Basic Service Library" to the learning queue. The system maintains a global set of learned repositories. When the number of repositories in the learning queue reaches a preset maximum number of tracked repositories (e.g., 5), no new external code libraries are added to the queue, thus achieving diffusion control. External code libraries added to the queue will be processed according to the same seed exploration and BFS chain learning process after the current repository has been learned, forming a cross-repository chain learning.

[0067] like Figure 4 The diagram illustrates a code learner, divided into two main phases. The upper left side represents "Phase One: Local Static Analysis (Zero LLM Overhead)": GitLab API pulls the complete repository directory tree → Regular expression parsing of import statements in each Java file → Construction of a directed dependency graph (nodes = files, edges = imports) + inverted index from class name to file → By class name suffix (… Controller / Resource / Consumer / Listener / Job / Scheduler / The seed file is identified by either Config or entry annotations (@Controller / @KafkaListener / @Scheduled, etc.). The upper right section is "Phase Two: BFS Chained Learning Starting from the Seed (Functional Unit)": Starting from the seed file, traverse the dependency graph using BFS, from the Controller method entry point to the Service layer, then to the DAO layer, and finally to the Entity data entity. Each node generates a functional summary using LLM, forming a complete call chain learning unit. The middle section explains "Cross-Repository Chained Learning": importing external repository classes → adding them to the learning queue → deduplicating the global "Learned Repository Collection" → maximum number of followed repositories = 5 (to prevent infinite diffusion). The lower section is "AST Semantic Boundary Blocking," which divides the learning results into chunks by class / method / enumeration and stores them in three storage layers: ① ChromaDB vector library (embedding semantic retrieval), ② local JSONL (categorized by business domain), ③ GitLab repository (persistent backup).

[0068] Optionally, an external code repository refers to another code repository that is outside the target code repository being studied and is depended upon by the target code repository through reference declaration.

[0069] Optionally, the identification of external code repositories can be based on the package path prefix in the reference declaration. Specifically, when the import statement of a code file contains a declaration of the form "import com.xxx.yyy.ClassName", the system will extract the package path prefix "com.xxx.yyy" and compare it with the package path prefix of the current target code repository. If the two do not match, the reference declaration is determined to involve an external code repository. It should be noted that the external code repository can be other microservice repositories under the same project group, or it can be an independent public component library or basic service library. Considering the frequent cross-repository calls between different services in a microservice architecture, automatically identifying external code repositories and including them in the learning scope can ensure that the integrity of the business call chain is not interrupted. If the package path prefix corresponding to some reference declarations cannot be clearly attributed to any known repository, the system can further use the directory mapping configuration table of the code repository for matching and searching, or temporarily mark the reference as pending confirmation, and process it after the mapping relationship is manually supplemented. This application does not limit this.

[0070] Optionally, the learning queue is a data structure used to temporarily store discovered external code libraries and trigger their chained learning tasks in sequence.

[0071] Optionally, the learning queue can adopt a first-in, first-out (FIFO) queue structure or a priority queue structure with priority markers. In FIFO mode, the system starts learning tasks sequentially according to the order in which external code repositories are discovered. In priority queue mode, the system assigns priority weights to external code repositories based on their frequency of citation or the number of citation sources, with repositories with higher citation frequencies being learned first. It should be noted that each entry in the learning queue, in addition to recording the external code repository's identification information, can also include contextual information such as the source file path where the external code repository was discovered, the reference type (e.g., class reference, interface reference), and the discovery timestamp. This information helps to quickly locate dependency entry points during subsequent chained learning. To avoid the same external code repository being added to the queue repeatedly, the system queries the global set of learned repositories before enqueuing an external code repository. If the repository already exists in the set, the enqueue operation is skipped, thus ensuring the uniqueness and efficiency of the learning tasks.

[0072] Optionally, diffusion constraints are constraint mechanisms used to control the scope of cross-warehouse chained learning to prevent the learning task from expanding indefinitely.

[0073] Optionally, diffusion constraints may include, but are not limited to, at least one of the following: a maximum number of repositories to be tracked, a maximum recursion depth threshold, or a learning time budget limit. Taking the maximum number of repositories to be tracked as an example, the system maintains a global counter. This counter increments whenever a new external codebase is actually started for learning. When the counter reaches a preset threshold (e.g., 5), the system stops retrieving new repositories from the learning queue. Taking the maximum recursion depth threshold as an example, the system can set recursion levels for cross-repository learning. When tracing from repository A to repository B, and then from repository B to repository C, the recursion depth is 2. If the depth exceeds the preset limit, further tracing of that path is truncated. Considering that the dependencies between repositories in an enterprise-level microservice architecture may present a network or even ring structure, without constraints, the learning task may spread to dozens or even hundreds of repositories, leading to uncontrolled token consumption and excessively long learning cycles. By setting diffusion constraints, the system can achieve a balance between business knowledge coverage and resource consumption. For external codebases that are not learned due to constraints, the system can record their identification information in the logs so that operations personnel can assess whether manual supplementation is needed.

[0074] Optionally, chained learning refers to a progressive knowledge acquisition process that starts from the current code repository and traces and learns the relevant code logic in external code repositories level by level along cross-repository reference relationships. Optionally, the execution flow of chained learning can specifically include: after the BFS traversal of the current repository is completed, the system retrieves the next external code repository from the learning queue and repeats the complete process of directory tree retrieval, import statement parsing, directed dependency graph construction, seed file identification, and BFS traversal to extract functional summaries for that external code repository. During chained learning, the system can maintain an independent set of code knowledge blocks for each external code repository being learned, and mark its source repository identifier and referenced path in the knowledge blocks, enabling the Agent to trace which repositories a certain business function crosses and the call relationships between the repositories when retrieving code knowledge. It should be noted that chained learning does not learn all files in the external code repository, but only the classes referenced by the current repository and the files on their dependency chains, thereby maximizing the control of the learning scale while ensuring the integrity of the business context. If an external codebase references an even outer codebase, chained learning will continue to advance and trace within the constraints of diffusion limitations, forming a multi-level cross-repository knowledge chain.

[0075] In an optional implementation, before extracting the functional summary from the searched code files, the runtime call chain trajectory of the corresponding function in the code files is obtained; the directed dependency graph is corrected based on the call chain trajectory to obtain an enhanced dependency graph; wherein, traversal learning is performed based on the enhanced dependency graph. In this way, correcting the static directed dependency graph through the runtime call chain trajectory can compensate for the shortcomings of static parsing in covering implicit dependency scenarios such as dynamic proxies and reflection calls, making the traversal learning path of code knowledge more complete and accurate.

[0076] In one implementation, taking a transaction service project as an example, the directed dependency graph constructed during the static parsing phase only shows a direct reference to the transaction service layer by the transaction controller class. However, at runtime, the call chain trace collected by the link tracing component shows that the controller also indirectly calls the risk control service class in the risk control verification module via a dynamic proxy. The system adds this actual runtime call relationship as a supplementary edge to the directed dependency graph, forming an enhanced dependency graph. Subsequent breadth-first search traversal can then cover this hidden dependency path of risk control verification, ensuring that the functional summary extraction does not miss any key business logic nodes.

[0077] Optionally, the call chain trace is used to characterize the actual sequence of method calls that occur during application runtime, serving as a supplementary data source for revising the directed dependency graph.

[0078] Optionally, the call chain trace can be the actual method call sequence data collected by performing link tracing on the application corresponding to the target code library during runtime. Considering that the directed dependency graph constructed by statically resolved reference declarations cannot identify implicit dependencies such as reflection calls, dynamic proxies, and event-driven mechanisms, as a possible implementation, the above-mentioned call chain trace can be automatically collected by a distributed link tracing component during application runtime. Its data content can include the timestamp of the method call, the class names and method signatures of the caller and callee, call depth, and time consumption. It should be noted that the collection scope of the call chain trace can cover method calls within a single microservice, or it can collect remote procedure call chains across service boundaries. The specific collection granularity can be flexibly adjusted according to the complexity of the business system and the configuration parameters of the tracing component, and this application does not limit it in this regard.

[0079] Optionally, the enhanced dependency graph is a directed graph structure obtained by fusing runtime call chain trajectories and used to replace the original dependency graph for traversal learning. Alternatively, the enhanced dependency graph can be a modified graph structure obtained by fusing implicit dependencies revealed by runtime call chain trajectories on top of the original directed dependency graph. Specifically, the construction process of the enhanced dependency graph may include: mapping each actual method call relationship in the call chain trajectory to a new edge in the directed dependency graph; if the edge already exists in the original graph, it is skipped to avoid redundancy; if it does not exist, it is added to the graph and labeled as a runtime supplement. To avoid excessive expansion of the dependency graph due to occasional calls, a call frequency threshold can be set, and only call relationships with a frequency exceeding the threshold can be included in the enhanced dependency graph. It should be understood that the node definitions in the enhanced dependency graph are consistent with the original directed dependency graph, still using code file paths as node identifiers, so that subsequent breadth-first search traversal logic can be directly executed based on the enhanced dependency graph without additional adaptation.

[0080] In step S250, feedback information during the interaction process is detected. In response to feedback information meeting preset conditions, the mapping relationship between object identifiers and business terms is constructed or updated based on the feedback information. In this way, by detecting feedback information in real time and automatically converting corrective content into knowledge updates, the knowledge base achieves self-evolution, avoids the recurrence of similar errors, and effectively improves the accuracy and robustness of the intelligent agent's answers. In one implementation, when a user finds an error in the intelligent agent's answer and sends "Wrong answer, should check the Post_SerialCollection table," the system detects that the feedback information meets preset conditions, extracts the business term "serialized collection" from historical questions, and writes it back as an alias to the mapping relationship in the Post_SerialCollection table, so that the same question can be correctly matched the next time.

[0081] Optionally, feedback information is used to indicate deviations in the responses provided by the intelligent agent in historical interactions. This feedback can take various forms, including text snippets, structured instructions, or query statements. Optionally, feedback information can be natural language correction text entered by the user in the dialogue interface, such as "Incorrect query" or "Should look up a certain table," or it can be structured teaching information or example query statements directly provided by the user. Considering that the intelligent agent may give incorrect answers in real-world business scenarios due to the knowledge base not covering specific terms, capturing and parsing the above feedback information in real time can accurately pinpoint knowledge blind spots. It should be noted that the acquisition of feedback information is not limited to the immediate input of the current round; it can also include batch retrospective analysis of historical dialogue records, thereby supporting knowledge review and supplementation in offline mode, ensuring the comprehensiveness and flexibility of knowledge evolution.

[0082] Optionally, preset conditions are used to determine whether feedback information is valid enough to trigger knowledge updates. These conditions can be set based on keyword matching, sentence structure parsing, or specific identifier recognition. Optionally, preset conditions may include at least one of the following: the feedback information contains preset corrective keywords, the feedback information contains a query statement that conforms to a specified pattern, or the feedback information contains a clear data object identifier. To avoid invalid knowledge updates due to arbitrary user input or irrelevant complaints, the system must perform strict verification when feedback information is detected. For example, when a user message matches keywords such as "searched incorrectly" or "should have searched," it is considered to meet the conditions; or when a valid data definition statement is parsed from the user message, it can also be triggered. If the feedback information does not meet any of the above conditions, the feedback is ignored, thereby ensuring the purity of the knowledge base and the accuracy of updates.

[0083] Optionally, the mapping relationship between object identifiers and business terms is used to establish a bridge between business concepts and underlying data objects. It can include a primary identifier and multiple auxiliary aliases. Optionally, the object identifier can be a table name or field name in the database, and the business terms can be natural language vocabulary used by users during interaction. The construction or updating of the mapping relationship specifically involves appending extracted candidate business keywords as auxiliary aliases to the index entries of the corresponding object identifiers. Considering that the same business concept may have multiple names among different user groups, dynamically expanding the alias index can significantly improve the intelligent agent's compatibility with diverse questions. During the update process, the system performs deduplication checks to ensure that existing aliases are not written repeatedly, and simultaneously synchronizes the updated mapping relationship to the persistent storage layer to ensure the consistency and high availability of knowledge data.

[0084] In an optional implementation, feedback information during the interaction process is detected. In response to feedback information meeting preset conditions, a mapping relationship between object identifiers and business terms is constructed or updated based on the feedback information. This includes: identifying text fragments containing correction content from the feedback information and determining the corresponding data object based on the correction content; extracting candidate keywords from historical interaction text corresponding to the feedback information and adding the candidate keywords as auxiliary identifiers to the mapping relationship entries of the data objects. In this way, by identifying correction content and determining the correct data object from the feedback information, and then extracting candidate keywords from historical interaction text as auxiliary identifiers to add to the mapping relationship entries, knowledge is automatically extracted and accumulated from user correction behavior, enabling the intelligent agent to evolve itself and preventing the recurrence of similar errors.

[0085] like Figure 5 The diagram illustrates a negative feedback self-learning closed loop, showcasing the complete closed loop from incorrect answers to self-learning by the agent. The process proceeds from top to bottom: S1 "Real-time detection of corrective behavior" (triggered by any of three rules: corrective keywords such as "incorrect / should be checked / correct table is / incorrect"; SQL statements are used to locate the correct table name from the FROM clause; structured statements specify the correct table name such as "this should be checked in the Trade_Order table"), triggering S2 "Extracting candidate business keywords from the original incorrect answer" (Chinese n-gram segmentation n=2,3,4 → filtering stop words), then S3 "Determining the correct table name from the correct information" (SQL FROM clause extraction / structured parsing), then S4 "Appending candidate keywords as aliases to the correct table alias index" (written to terms.yaml, deduplication strategy), and finally S5 "Dual-channel broadcast synchronization" (channel a pushes to the GitLab repository as a persistent backup, channel b broadcasts terminology changes via Redis Pub / Sub + increments the global knowledge version number to cover broadcast loss). The bottom shows the closed-loop effect: the agent encounters the same question again → hits the new alias → answers correctly (knowledge flywheel), and all Pods in the cluster receive the change → hot update the local knowledge index → ​​the next query takes effect immediately.

[0086] In one implementation, a user asks the system, "Please check my grain coupon balance." The system incorrectly queries the BlogInfo table and returns irrelevant results. The user then enters, "I made a mistake; I should have checked the User_GrainTicket table." The system detects the corrective keyword "made a mistake" in the message and determines that a negative feedback self-learning process is triggered. From the user's original question, "Please check my grain coupon balance," the system segments consecutive Chinese characters to generate candidate word groups such as "grain coupon," "balance," and "grain coupon balance." After filtering out stop words like "Please help me" and "check," it retains "grain coupon" and "grain coupon balance" as candidate keywords. Simultaneously, the system determines the correct data object from the user's correction information as the User_GrainTicket table and appends "grain coupon" and "grain coupon balance" as auxiliary identifiers to the mapping entries in this table. Subsequently, when other users ask questions using the expression "grain coupon," the system can correctly match the User_GrainTicket table, achieving self-evolution of knowledge.

[0087] Optionally, the correction content may include at least one of corrective keywords, example query statements, or structured object indication information, used to locate the data object that the user believes is correct. Optionally, correction content refers to the information fragment provided by the user during the interaction process when correcting or revising the previous response. Considering the diversity of ways users express their correction intentions, as a possible implementation, the correction content can be presented in several forms: The first form is natural language text containing corrective keywords, such as when the user inputs words like "incorrect," "should be checked," "wrong," or "the correct table is," and the system identifies the message as correct through keyword matching; the second form is an example structured query statement directly provided by the user, from which the system parses the name of the data table that the user believes is correct from the data source clause of the statement; the third form is a correct object identifier explicitly indicated by the user in a structured format, such as "this should be checked in the Trade_Order table." It should be noted that the above three forms can trigger correction identification individually or in combination to enhance the accuracy of identification. When the system detects any of the above forms of correction content, it further extracts or parses the corresponding data object identifier from it as the target object for subsequent knowledge updates. Through a multi-dimensional and multi-form corrective content recognition mechanism, the system can cover user groups with different expression habits and improve the recall and accuracy of negative feedback detection.

[0088] Optionally, in addition to identifying correction content based on keyword matching and sentence parsing, a semantic understanding model can be used to classify user messages by intent, determining whether they constitute a correction intent. Specifically, the current user message and the context of the previous response can be input into a semantic classification model. The model outputs a confidence score indicating whether the message contains a correction intent. If the score exceeds a preset threshold, it is determined to be correction content. The advantage of this approach is its ability to identify implicit correction expressions. For example, a user inputting "This result isn't quite right," while not containing explicit correction keywords, semantically expresses a correction intent. Furthermore, for identified correction content, the system can also perform a confidence assessment. When the clarity of the correction content is low, a secondary confirmation process can be triggered, asking the user for more accurate correction information to avoid incorrect knowledge being written into the mapping relationship entries due to misjudgment.

[0089] Optionally, historical interaction text may include the original question asked by the user before correction and its contextual dialogue content, used to extract candidate business keywords. Optionally, historical interaction text refers to previous interaction records that are related to the current feedback information. Specifically, it may include the original question text asked by the user before correction, and the dialogue content of several rounds before and after that question. Considering that the terminology used by users when expressing business needs may differ from the standard terminology already known to the system, the system needs to extract the actual business expressions used by the user from historical interaction text. In one implementation, the scope of historical interaction text acquisition can be configured to only take the original question from the round that was corrected, or it can be expanded to include the contextual dialogue of a preset number of rounds before that question, to provide a richer semantic background. It should be noted that the selection of historical interaction text is not unlimited. The system can determine the effective scope based on time windows, session identifiers, or topic boundaries to avoid introducing noisy text unrelated to the current correction. Through accurate positioning and extraction of historical interaction text, the system can capture the business vocabulary and expression habits actually used by the user, providing a reliable textual basis for the generation of subsequent candidate keywords, thereby making the auxiliary identifiers for rewriting more consistent with the user's actual query language.

[0090] Optionally, candidate keywords can include phrases with business-specific meaning retained after segmenting historical interaction text into continuous substrings and filtering out stop words. Alternatively, candidate keywords are a set of keywords with actual business-specific meaning retained after segmenting historical interaction text into continuous substrings and filtering out stop words. Specifically, continuous Chinese characters in historical interaction text are segmented using n-grams (continuous n-gram syntax) to generate all possible continuous Chinese combinations. The value of n can be configured according to the length characteristics of business terms, for example, 2 to 4, generating two-character phrases, three-character phrases, and four-character phrases respectively. Subsequently, the system compares the generated candidate phrases with a predefined stop word list, filtering out generic words without business-specific meaning such as "query," "how much," "how," "can," and "please," retaining candidate keywords with actual business semantics. It's important to note that the granularity of n-gram segmentation directly impacts the quality and quantity of candidate keywords. Smaller n values ​​produce more fine-grained phrases but may include meaningless segments, while larger n values ​​may miss short terms. Therefore, the system can support multiple combinations of n values ​​and eliminate duplicate phrases through deduplication strategies. The candidate keywords obtained after this processing will serve as a source of auxiliary identifiers, providing accurate vocabulary material for updating mapping entries.

[0091] Optionally, auxiliary identifiers may include alias information appended to the data object mapping entries to expand the business terminology coverage of the object identifier. Optionally, auxiliary identifiers refer to supplementary identifier information appended to the mapping entries of a data object, whose function is to expand the range of business terms that the data object can match, ensuring correct identification when users use different expressions to refer to the same data object. In one implementation, the auxiliary identifier specifically manifests as an alias for a data table. For example, when a user uses the expression "serialized collection" and the standard identifier for the data table in the system is "Post_SerialCollection", "serialized collection" is appended as an auxiliary identifier to the mapping entry of that table. The writing of auxiliary identifiers employs a deduplication strategy. Before appending, the system checks whether the same auxiliary identifier already exists in the current mapping entry; if it already exists, the writing is skipped to avoid redundancy. Furthermore, the sources of auxiliary identifiers are not limited to negative feedback self-learning paths; they can also include field comment information extracted by the offline learner from data definition statements, terminology mappings identified by the code learner from business code, and other sources. Auxiliary identifiers from multiple sources together constitute a complete alias index for the data object. Through the continuous accumulation of auxiliary identifiers, the mapping relationship entries of data objects can be continuously enriched, enhancing the intelligent agent's ability to understand diverse user expressions.

[0092] In an optional implementation, candidate keywords are extracted from the historical interaction text corresponding to the feedback information. This includes: segmenting the historical interaction text into continuous substrings to obtain candidate word groups; filtering stop words from the candidate word groups, and using the remaining candidate word groups as candidate keywords. In this way, by segmenting the original question into multi-granular character combinations and removing meaningless high-frequency words, keywords with business differentiation can be automatically extracted from the user's natural language input, eliminating the need for manual annotation and providing a reliable data source for the automatic construction and write-back of alias indexes.

[0093] In one implementation, assuming the user's original question in the previous round was "Query grain coupon balance", the system performs segmentation processing on the continuous Chinese characters in the question. Specifically, the continuous substring segmentation processing may include: (1) performing 2-character segmentation on "Query grain coupon balance" to obtain candidate word groups such as "Query", "Inquire about grain", "Grain coupon", "Coupon balance", and "Balance"; (2) performing 3-character segmentation to obtain candidate word groups such as "Query grain", "Inquire about grain coupon", "Grain coupon balance", and "Coupon balance"; and (3) performing 4-character segmentation to obtain candidate word groups such as "Query grain coupon", "Inquire about grain coupon balance", and "Grain coupon balance". Subsequently, the system filters out common stop words such as "Query" from the above candidate word groups and retains candidate keywords such as "Grain coupon", "Balance", and "Grain coupon balance" that have actual business differentiation significance. These keywords will be added as aliases to the mapping relationship entries of the correct data table.

[0094] Optionally, historical interaction text refers to the original user question that triggered the negative feedback learning round, and its source includes natural language input from the dialogue history. Alternatively, historical interaction text refers to the original question text entered by the user during interaction with the intelligent agent, which was answered incorrectly by the intelligent agent. It should be noted that historical interaction text does not refer to all dialogue records in general, but specifically to the original question posed by the user in the round of interaction that triggered the negative feedback self-learning process. Historical interaction text can be pure Chinese text, mixed Chinese and English text, or natural language sentences containing punctuation and numbers. In specific implementation, the system locates the original question corresponding to the current corrective action from the dialogue history using a session identifier or timestamp, and uses it as the input source for keyword extraction. Considering the diversity and colloquial nature of user question expressions, the length and content structure of historical interaction text are unrestricted. The system can adapt to inputs of different lengths and expression habits when performing subsequent segmentation processing, ensuring that candidate business keywords can be effectively extracted from short questions to complex long sentences.

[0095] Optionally, continuous substring segmentation involves generating character combinations by sliding values ​​through the text according to a preset window length, implemented using n-gram technology. Specifically, continuous substring segmentation refers to the process of generating all possible combinations of continuous characters by sliding values ​​through a preset window length for consecutive characters in historical interactive text. This process uses n-gram (a technique in natural language processing that segments text into a sequence of n consecutive words), where n ranges from 2 to 4, generating continuous substrings of 2, 3, and 4 characters respectively. For example, for the question "How to find a collection of serialized texts", 2-character segmentation yields "serialized text", "collection", "collection", "collection", "how", "how to find", 3-character segmentation yields "serialized text", "collection", "collection", "how to find", and 4-character segmentation yields "serialized text", "collection", "collection", "collection". It should be noted that the value of n is not limited to 2 to 4, and can be extended according to the length distribution characteristics of business terms, such as adding 1-character or 5-character segments. This segmentation process is performed entirely locally, without relying on a language model, with extremely low processing cost, and can guarantee exhaustive coverage of candidate word groups.

[0096] Optionally, besides the fixed-window-length n-gram segmentation method mentioned above, continuous substring segmentation can also employ a variable-length window strategy or a segmentation method assisted by word segmentation tools. In the variable-length window strategy, the system can pre-segment the question into several short sentence segments based on natural delimiters such as punctuation marks or spaces identified in the historical interactive text, and then perform n-gram segmentation independently on each short sentence segment, thereby avoiding the generation of meaningless candidate word groups across punctuation marks. In the word segmentation-assisted method, a Chinese word segmentation tool can be used to perform preliminary word segmentation on the question, and then continuous word items in the segmentation results can be combined and segmented to improve the semantic integrity of candidate word groups. The above-mentioned segmentation strategies can be used individually or in combination, and this application does not impose any limitations on this.

[0097] Optionally, candidate word groups are the set of all continuous character combinations generated after continuous substring segmentation, which is intermediate data before stop word filtering.

[0098] Optionally, candidate word groups refer to the set of all continuous character combinations generated after segmenting a continuous substring, serving as an intermediate product before filtering stop words. Candidate word groups include both valid word groups with business distinguishing significance and transitional character combinations without actual semantic meaning. For example, after segmenting the question "guess the status of the activity," candidate word groups include "guess," "guess the activity," "activity," "dynamic state," "state," "guess the activity," "guess the activity," "activity state," "dynamic state," etc., among which "guess the activity" and "dynamic state" are transitional combinations without business meaning. The number of candidate word groups is positively correlated with the length of the historical interaction text; the longer the text, the more candidate word groups there are. After generating candidate word groups, the system does not directly write them all into the knowledge base but requires a stop word filtering process to ensure that the final retained candidate keywords have sufficient business distinguishing significance and avoid invalid word groups polluting the alias index.

[0099] Optionally, stop words are high-frequency words or character combinations that lack business-specific meaning, and they are filtered through a pre-defined stop word list. Optionally, stop words refer to words or character combinations that frequently appear in natural language but lack business-specific meaning, including but not limited to general verbs, interrogative words, modal particles, and conjunctions. Specifically, stop words can include common interactive phrases such as "query," "how much," "how," "can," "please," "what," "why," "not," and "this." The system maintains a stop word list, and after generating candidate word groups, it compares them one by one with the stop word list, removing candidate word groups that match the stop word list. It should be noted that the content of the stop word list can be customized according to the characteristics of the business domain; different business domains can maintain their own stop word lists. For example, in the transaction domain, "order" may be a core business term rather than a stop word, but certain high-frequency words in general interactive contexts need to be filtered. In addition, the stop word list supports dynamic updates. When the system finds that certain phrases appear repeatedly but have never been adopted as valid aliases, they can be automatically added to the stop word list, thereby continuously optimizing the filtering accuracy.

[0100] In step S270, based on the first type of summary information, the second type of summary information, and the mapping relationship, knowledge data is output in response to the knowledge call request. In this way, by integrating the summary information and mapping relationship generated from multi-path learning to respond to the knowledge call request and output knowledge data, the intelligent agent can obtain accurate business knowledge support with minimal lexical cost, effectively improving the quality of answers and response efficiency.

[0101] In one implementation, when a user asks the intelligent agent "What was the readership of the serialized collection last month?", the intelligent agent first parses the question and generates a knowledge retrieval request. After receiving the request, the system loads the L0 layer business domain index (determining that the question belongs to the "content payment domain"), the L1 layer table summary and term mapping (hitting the Post_SerialCollection table corresponding to "serialized collection") according to the layered strategy. When SQL needs to be written, the system obtains the complete L2 layer table structure as needed through a dedicated tool. Finally, the combined knowledge data is injected into the intelligent agent context to generate an accurate answer.

[0102] Optionally, a knowledge retrieval request is used to trigger the hierarchical knowledge loading process. It can be automatically generated by the intelligent agent after receiving a user's question, or it can be proactively initiated by the system when a specific business scenario is detected.

[0103] Optionally, a knowledge retrieval request refers to a data retrieval instruction initiated by the intelligent agent to the knowledge management system when processing user interaction tasks in order to obtain the required business knowledge. This request can be automatically generated by the intelligent agent after receiving a user's natural language question, or it can be proactively triggered by the system when it detects a specific business scenario (such as SQL writing requirements or code logic query requirements). The knowledge retrieval request can carry contextual information such as business domain identifiers, keywords, and request types, enabling the knowledge management system to accurately locate the required knowledge level. It should be noted that the above description of the triggering timing and content of the knowledge retrieval request is only one example, and this application is not intended to limit it. In addition to being automatically generated by the intelligent agent, query instructions from external systems or manually configured queries can also be received as knowledge retrieval requests to adapt to different knowledge supply scenarios.

[0104] Optionally, the knowledge data includes business domain indexes, object summaries, terminology mapping relationships, and complete structural information loaded through a hierarchical strategy, which are dynamically combined and output according to the hierarchical requirements of the knowledge retrieval request.

[0105] Optionally, knowledge data refers to the structured knowledge content output by the knowledge management system in response to knowledge call requests, after being filtered and combined using a layered loading strategy. Knowledge data may include business domain index information (such as domain-level summaries for transaction domains, user domains, and content payment domains), object summaries and terminology mapping relationships (such as Chinese usage descriptions of data tables, field meanings, enumeration value comparisons, and alias mappings from business terms to table names), and complete structural information (such as DDL statements for data objects and functional summaries of code files). The output granularity and content combination of knowledge data can be dynamically adjusted according to the hierarchical requirements of the knowledge call request. For example, only about 200 terms of domain index information may be output at the L0 level, about 500 terms of intra-domain summaries and mappings may be output at the L1 level, and the complete structure may be output as needed at the L2 level. It should be noted that the above-mentioned layered granularity and token control threshold for knowledge data are only illustrative examples and can be configured and adjusted according to the actual business scale and resource conditions. This application is not intended to limit this.

[0106] In an optional implementation, based on the first type of summary information, the second type of summary information, and the mapping relationship, knowledge data is output in response to a knowledge retrieval request. This includes: loading the corresponding knowledge data according to a preset hierarchical strategy, which includes: loading global business domain index information; when the knowledge retrieval request hits a specific business domain, loading the object summary and term mapping relationship within that specific business domain; and retrieving the complete structure of the data object as needed in response to a complete structure retrieval request. In this way, by loading knowledge data step by step according to a preset hierarchical strategy, the problems of excessive resource consumption and decreased positioning accuracy caused by injecting all knowledge into the context at once are avoided, effectively reducing the processing cost of a single request while ensuring knowledge coverage.

[0107] In one implementation, upon receiving a user's query request, the system first loads global business domain index information, which includes lists of transaction domains, user domains, and content domains. Based on this index, the language model determines that the user's question belongs to the "content payment domain," and then the system loads object summaries and terminology mappings within that domain. When the language model needs to write a specific query statement, a dedicated tool triggers a complete structure retrieval request, obtaining the complete table structure definition of the corresponding data objects on demand, thus completing knowledge provision in a progressive manner. Optionally, a preset hierarchical strategy is used to control the amount of knowledge data injected, loading knowledge content of different granularities level by level according to the matching depth of the knowledge call request.

[0108] Optionally, the preset layering strategy can include multiple progressive layers, such as a base index layer, an intra-domain summary layer, and a full structure layer. The base index layer is loaded with each request and contains a list of global business domains to help the language model determine the business domain to which the user's question belongs. The intra-domain summary layer is loaded when the base index layer hits a specific business domain and contains summaries of objects and terminology mappings within that domain. The full structure layer is not pre-injected but is retrieved on demand when the language model needs to generate specific operation statements. Through this progressive loading, the amount of knowledge injected in a single request can be controlled to the level of several hundred words, reducing resource consumption by approximately 90% compared to the full injection method.

[0109] Optionally, in addition to the three-layer structure mentioned above, the layered strategy can be extended to more layers based on business complexity. For example, a cross-domain association layer can be added to load association mapping information when a request involves a joint query across multiple business domains. It should be noted that the division and loading order of the layers can be dynamically adjusted based on the actual system's resource constraints and response latency requirements. If system resources are sufficient and response latency requirements are extremely high, the basic index layer and the intra-domain summary layer can be loaded together. For resource-constrained scenarios, the intra-domain summary layer can be further split, loading term mappings first, and then loading object summaries as needed. This application does not intend to limit the specific number of layers or the method of division for this strategy.

[0110] Optionally, the global business domain index information provides a global view of the business domain, containing identifiers for multiple business domains and their corresponding query cache directories. Optionally, the global business domain index information can be a collection of domains divided according to business modules or functions, such as transaction domains, user domains, ecosystem domains, growth domains, and content payment domains. In addition to a list of business domain names, this index information can also include a question-and-answer cache directory or quick navigation guide for each business domain. Considering that the full knowledge base may reach thousands or even tens of thousands of entries, the global business domain index information is made a mandatory item for every request, and its data volume can be controlled to a very small range (e.g., about two hundred words). By reading this index information, the language model can quickly locate the business domain to which the user's intent belongs, thus providing a navigation foundation for loading more granular knowledge subsequently and avoiding performance degradation caused by blindly searching in extremely long contexts.

[0111] Optionally, a complete structure retrieval request is used to trigger the loading of the underlying structure of a data object, generated in response to a tool call instruction from the language model. Alternatively, a complete structure retrieval request can be an instruction triggered when the language model determines that a structured query statement needs to be written or data operations need to be performed. When the system has only loaded the domain summary and term mapping, the language model may have already identified the target data object but lack detailed information at the field level. In this case, the language model can initiate this request by calling a pre-defined dedicated tool (e.g., an interface for retrieving table structures). In response to this request, the system retrieves the complete data definition statement or field details of the corresponding data object from local files or cache and returns it. This on-demand retrieval mechanism ensures that only truly necessary fine-grained data is injected into the context, further reducing unnecessary resource overhead while guaranteeing the accuracy of the operation statements generated by the language model.

[0112] In an optional implementation, the first type of summary information, the second type of summary information, and the mapping relationship are persisted and synchronized to multiple service nodes, enabling the service nodes to respond to knowledge call requests based on the synchronized knowledge data. This multi-layered persistence and cross-node synchronization mechanism ensures high availability and no loss of knowledge data in system failures or container migration scenarios, while also guaranteeing the consistency of knowledge state across all nodes in the cluster, thereby improving the accuracy and real-time performance of responding to knowledge call requests.

[0113] In one implementation, when the negative feedback self-learning mechanism updates the alias index of a data table, the system synchronously writes the updated knowledge data to local files and a remote code repository for persistence. Simultaneously, the change event is broadcast to all service nodes in the cluster via the publish-subscribe mechanism of the caching system, enabling each service node to immediately hot-update its local knowledge index and respond to subsequent knowledge call requests based on the latest synchronized knowledge data. Optionally, persistence processing is used to write the knowledge data to at least one storage medium to achieve long-term data preservation and disaster recovery backup.

[0114] Optionally, persistence processing can include storage strategies across multiple dimensions, such as a vector database layer, a local file persistence layer, and a remote code repository layer. Considering the risk of knowledge data loss in the event of system failures or container restarts, as a possible implementation, the above persistence processing adopts a three-layer stacking mechanism: the first layer stores the semantic vectors of code knowledge in a vector database to support retrieval; the second layer writes the structured knowledge index into a local file in a specific format; and the third layer automatically pushes the data to a remote code repository via a background thread for version control. It should be noted that the above three-layer storage strategy is merely an example, and this application does not intend to limit the number of persistence layers. In actual implementation, two layers or additional storage media can be selected based on resource availability. If an anomaly occurs in one layer of storage, the system can rely on the remaining layers for data recovery, thereby ensuring the security of knowledge assets.

[0115] Optionally, in addition to the aforementioned three-layered static storage strategy, persistence can also be combined with a checkpoint mechanism to enable breakpoint continuation. To prevent the processed knowledge data from being incompletely persisted to disk after a batch learning task is interrupted due to external factors, the above method saves a corresponding checkpoint archive file after each batch of data objects or code files is learned. This archive file records the list of objects that have been learned, failed objects, and objects to be processed. When the learning process resumes, the system automatically checks the archive file and continues the unfinished persistence operations. This dynamic persistence strategy not only avoids repetitive work but also ensures the integrity of knowledge data during the generation process, further improving the system's robustness in complex operating environments.

[0116] Optionally, service nodes are used to host the runtime environment for knowledge data and respond to external knowledge access requests.

[0117] Optionally, service nodes can be containerized instances, physical machines, or virtual machines. Considering the need for knowledge data consistency across multiple nodes in a clustered environment, as a possible implementation, when knowledge on a service node changes, the change event is broadcast to all subscribing nodes via the publish-subscribe mechanism of the caching system. Each service node automatically hot-updates its local knowledge index upon receiving the change, ensuring that the next query takes effect immediately. It should be understood that in the event of lost publish-subscribe messages, the system can also use a global knowledge version number for fallback detection. Service nodes synchronize the version number locally upon startup and then periodically compare it; if the local version is found to be outdated, a full knowledge reload is triggered. This multi-channel synchronization mechanism effectively avoids data inconsistency problems caused by message loss.

[0118] Optionally, when responding to knowledge call requests, service nodes can dynamically adjust their knowledge data loading strategy based on their own resource load. To avoid memory overflow or response delays caused by a single node loading the full amount of knowledge, service nodes can adopt a layered, progressive loading approach to handle requests. Upon receiving a request, basic index information is loaded first, detailed summaries are loaded only when a specific business domain is hit, and complete structural information is retrieved on demand. If a node experiences excessive load, the system can forward some knowledge call requests to other nodes with lower loads. Through this inter-node collaboration and load balancing, not only is the consistency of knowledge data ensured, but the overall throughput and stability of the cluster in responding to knowledge call requests are also improved.

[0119] A knowledge management device according to one embodiment of this application, such as Figure 6 As shown, the device may include: The first acquisition module is used to acquire the structured definition information of data objects in the target database, and extract the first type of summary information of the data objects based on the structured definition information; The second acquisition module is used to acquire the dependency relationships between code files in the target code library, determine at least one starting file from the target code library based on the dependency relationships, and traverse and learn along the dependency relationships starting from the starting file to obtain the second type of summary information of the target code library. The first response module is used to detect feedback information during the interaction process, and respond to feedback information that meets preset conditions, and build or update the mapping relationship between object identifiers and business terms based on the feedback information. The second response module is used to output knowledge data in response to a knowledge retrieval request, based on the first type of summary information, the second type of summary information, and the mapping relationship.

[0120] This approach enables automatic knowledge acquisition and self-evolution through feedback, reducing manual maintenance costs and token overhead for model calls, and improving the efficiency of knowledge management. Simultaneously, by using layered loading and on-demand retrieval, it reduces data processing pressure and memory resource consumption when the model processes context data, and minimizes redundant computational resource waste caused by repeatedly processing erroneous requests.

[0121] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0122] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the exemplary embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0123] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0124] The following is a detailed reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1201, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1202 or a program loaded from memory 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of the electronic device. The processor 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0125] Typically, the following devices can be connected to I / O interface 1205: input devices 1206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1208 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1209. Communication device 1209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0126] In particular, according to one embodiment of this application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, one embodiment of this application includes a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication device 1209, or installed from memory 1208, or installed from ROM 1202. When the computer program is executed by processor 1201, it performs the functions defined in the methods described above in various embodiments of this application.

[0127] Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0128] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0129] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0130] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A knowledge management method, characterized in that, The method includes: Obtain the structured definition information of data objects in the target database, and extract the first type of summary information of the data objects based on the structured definition information; Obtain the dependency relationships between code files in the target code library, determine at least one starting file from the target code library based on the dependency relationships, and perform traversal learning along the dependency relationships starting from the starting file to obtain the second type of summary information of the target code library; The system detects feedback information during the interaction process, and in response to the feedback information meeting preset conditions, constructs or updates the mapping relationship between object identifiers and business terms based on the feedback information. Based on the first type of summary information, the second type of summary information, and the mapping relationship, knowledge data is output in response to a knowledge retrieval request.

2. The method according to claim 1, characterized in that, The process of obtaining the dependencies between code files in the target code library includes: Parse the reference declarations in the code file and construct a directed dependency graph based on the reference declarations; In this context, the nodes of the directed dependency graph represent the code files, and the edges of the directed dependency graph represent the reference relationships between the code files.

3. The method according to claim 2, characterized in that, The step of determining at least one starter file from the target codebase based on the dependencies includes: The starting file is determined from the code file based on a preset starting point identifier; The starting point identifier includes the entry class name suffix and / or entry annotation.

4. The method according to claim 3, characterized in that, The step of traversing and learning along the dependency relationships starting from the starting file to obtain the second type of summary information of the target code library further includes: Starting from the starting file, a breadth-first search is performed along the directed dependency graph, and functional summaries are extracted from the searched code files to obtain the second type of summary information of the target code library.

5. The method according to claim 4, characterized in that, The breadth-first search along the directed dependency graph further includes: When the reference declarations of the searched code files involve external code libraries, the external code libraries are added to the learning queue; The learning queue is controlled based on preset diffusion constraints to achieve chained learning of the external code library.

6. The method according to claim 1, characterized in that, The step of obtaining the structured definition information of data objects in the target database and extracting the first type of summary information of the data objects based on the structured definition information includes: Scan the target database to obtain the data definition statement of the data object; The data definition statement is submitted to the language model, which then extracts the first type of summary information of the data object.

7. The method according to claim 1, characterized in that, The feedback information during the detection interaction process, in response to the feedback information meeting preset conditions, involves constructing or updating the mapping relationship between object identifiers and business terms based on the feedback information, including: Identify text fragments containing correction content from the feedback information, and determine the corresponding data objects based on the correction content; Candidate keywords are extracted from the historical interaction text corresponding to the feedback information, and the candidate keywords are added as auxiliary identifiers to the mapping relationship entries of the data object.

8. The method according to claim 7, characterized in that, The step of extracting candidate keywords from the historical interaction text corresponding to the feedback information includes: The historical interactive text is segmented into continuous substrings to obtain candidate word groups; Filter out the stop words in the candidate word groups and use the remaining candidate word groups as the candidate keywords.

9. The method according to claim 6, characterized in that, The scanning of the target database includes: Monitor the change log stream of the target database, and obtain the structured definition information of the data object based on the data definition statement change event in the change log stream, so as to realize incremental updates to the target database.

10. The method according to claim 4, characterized in that, The method further includes: Before extracting the function summary from the searched code file, obtain the call chain trajectory of the function corresponding to the code file at runtime; The directed dependency graph is corrected based on the call chain trajectory to obtain an enhanced dependency graph; The traversal learning is performed based on the enhanced dependency graph.

Images