Requirement document auditing method and device, computing equipment, storage medium and product

Abstract

The embodiment of the invention provides a requirement document auditing method and device, computing equipment, a storage medium and a product. The method comprises the following steps: acquiring an auditing request for a target demand document sent by a user side, and analyzing the target demand document in a reasoning stage by using a multi-modal artificial intelligence module to determine key information corresponding to various modal data contained in the target demand document and at least one action plan involved in the target demand document; performing knowledge retrieval based on the at least one action plan in the action stage to determine reference data associated with the at least one action plan, and auditing the target demand document according to the key information and the reference data; generating an auditing report according to the auditing result; and feeding back the auditing report to the user side. According to the technical scheme provided by the embodiment of the invention, the auditing efficiency and accuracy of the demand document can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computing device, storage medium, and product for reviewing requirements documents. Background Technology

[0002] In the software development process, requirements documents, as formal documents that systematically describe the requirements of a product, service, or project, are used to clarify objectives, guide software development, and coordinate team collaboration. Because their quality directly impacts project delivery efficiency and the final product's outcome, the review process for requirements documents is crucial.

[0003] Currently, requirement documents are typically reviewed through manual meetings and discussions, which has the following limitations: 1. Low efficiency: Manual review is time-consuming, especially for longer requirement documents; 2. Low accuracy: Due to differences in the professional backgrounds of reviewers, the review results are greatly affected by subjectivity, and accuracy cannot be guaranteed. Improvement is urgently needed. Summary of the Invention

[0004] This application provides a method, apparatus, computing device, storage medium, and product for reviewing requirements documents, in order to solve the problems of low efficiency and low accuracy in the review of requirements documents in the prior art.

[0005] Firstly, this application provides a method for reviewing requirements documents, including:

[0006] Obtain the review request sent by the user client for the document targeting the requirements;

[0007] The target requirement document is parsed during the inference phase using a multimodal artificial intelligence module to determine the key information corresponding to each of the multiple modal data contained in the target requirement document, as well as at least one action plan involved in the target requirement document; during the action phase, knowledge retrieval is performed based on the at least one action plan to determine reference data associated with the at least one action plan, and the target requirement document is reviewed based on the key information and the reference data;

[0008] Based on the audit results, generate an audit report;

[0009] The audit report will be sent back to the user.

[0010] Secondly, embodiments of this application provide a requirement document review device, including:

[0011] The request retrieval unit is used to retrieve the review request sent by the user client for the target requirement document;

[0012] The intelligent parsing unit is used to parse the target requirement document during the inference phase using a multimodal artificial intelligence module to determine the key information corresponding to each of the multiple modal data contained in the target requirement document, as well as at least one action plan involved in the target requirement document; during the action phase, knowledge retrieval is performed based on the at least one action plan to determine reference data associated with the at least one action plan, and the target requirement document is reviewed based on the key information and the reference data.

[0013] The report generation unit is used to generate an audit report based on the audit results;

[0014] The report sending unit is used to send the audit report back to the user terminal.

[0015] Thirdly, this application provides a computing device, including a processing component and a storage component; the storage component stores a computing program; the computer program is used to be called and executed by the processing component to implement the requirement document review method as described in the first aspect above.

[0016] Fourthly, this application provides a computer storage medium storing a computer program, which, when executed by a processing component, implements the requirement document review method described in the first aspect above.

[0017] Fifthly, this application provides a computer program product, including a computer program or instructions, which, when executed by a processing component, implements the requirement document review method described in the first aspect above.

[0018] This application proposes a solution for reviewing requirement documents by deeply integrating ReAct AI Agent and RAGFlow. The basic idea is as follows: A review request for a target requirement document is received from the user client. During the inference phase, a multimodal AI module parses the target requirement document to determine the key information corresponding to each of the various modal data contained in the document, as well as at least one action plan involved. During the action phase, knowledge retrieval is performed based on at least one action plan to determine reference data associated with it. The target requirement document is then reviewed based on the key information and reference data. A review report is generated based on the review results and sent back to the user client. This embodiment combines the inference and action mechanisms of multimodal ReAct with the multimodal dynamic retrieval of RAGFlow to automatically complete the review task of requirement documents. No manual intervention is required, greatly improving review efficiency and reducing review costs. Furthermore, during the inference phase, ReAct extracts key information from multiple modalities of data in the requirements document and formulates at least one action plan. This empowers subsequent action phases with the ability to determine where and why to search, guiding RAGFlow to achieve precise retrieval during ReAct's action phase. Through the synergy of these two approaches, a qualitative leap is achieved from "single retrieval information" to "the evidence chain (i.e., reference data) for precise retrieval and review of the action plan." This enables a comprehensive and multi-dimensional review of the requirements document, something that neither a single retrieval nor a single parsing model can accomplish alone. Therefore, this solution can also greatly improve the accuracy of the review results.

[0019] This embodiment employs a collaborative architecture with ReAct AI Agent as the "brain" and RAGFlow as the "hands and feet." The reasoning capabilities of the ReAct AI Agent are used to parse key information in the target requirement document and generate a logically ordered chain of action plans (Think), i.e., at least one action plan. Its action capabilities are then specifically used to drive the RAGFlow dynamic retrieval engine for precise knowledge acquisition (Act). This mechanism, which tightly couples decision-making with retrieval, enables the system for reviewing requirement documents in this application to proactively initiate a series of purposeful, context-dependent retrieval actions, rather than passively responding to queries—something unprecedented in existing systems. Therefore, this embodiment is not merely a simple functional combination of the ReAct AI Agent and RAGFlow, but rather represents a new working paradigm.

[0020] These or other aspects of this application will become more apparent from the description of the following embodiments. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0022] Figure 1 This application provides a system architecture diagram for requirements document review.

[0023] Figure 2 A flowchart illustrating a requirement document review method according to one embodiment of this application is shown;

[0024] Figure 3 This illustration shows the effect of an audit report provided in this application;

[0025] Figure 4 This application provides a flowchart illustrating a method for reviewing requirements documents in a practical application scenario.

[0026] Figure 5 This invention provides a schematic diagram of the structure of a requirements document review device according to one embodiment of the present application.

[0027] Figure 6 A schematic diagram of the structure of the computing device provided in this application is shown. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0030] It should be noted that the technical solutions in this application are applicable to virtual network environments, and the users described generally refer to "virtual users." Real users can register user accounts on the server through registration to obtain user identities in the network environment. The same user account can log in to the server through different types of client terminals, enabling the server to identify the same user.

[0031] Interactions between the server and the user can be based on user accounts. The data received or sent by the server to the user is also based on the user account; in reality, the user's client, corresponding to the user account, receives or sends data to the server. Furthermore, users can also communicate with each other through their user accounts. Here, "user" can refer to an individual or an organization, such as a company; this application does not impose specific restrictions.

[0032] For ease of reference, some terms that may be used in this application are defined as follows. It is understood that the terms and their respective definitions are not strictly limited to these definitions, and terms may be further defined through their use in this application:

[0033] The ReAct framework is an artificial intelligence (AI) architecture that combines reasoning and acting. It enables the review of requirement documents through dynamic decision-making and the invocation of external tools. In this embodiment, the dynamic decision-making process belongs to the reasoning phase of the ReAct framework, while the external tool invocation process belongs to the action phase. This ReAct framework can promote a unified processing paradigm for multimodal documents (such as requirement documents) to solve the problem of multimodal information parsing in requirement document review tasks.

[0034] An intelligent agent can be an intelligent entity capable of perceiving its environment and taking actions to achieve specific goals. It is not limited to simple task execution but also possesses characteristics such as autonomy, responsiveness, initiative, and social capabilities. Its core elements include planning, memory, tool use, perception, decision-making, and action. The ReAct AI Agent in this embodiment is an intelligent agent framework that integrates reasoning and action capabilities, aiming to improve the performance, interpretability, and adaptability of large models in complex tasks through dynamic interaction and iterative optimization.

[0035] RAGFlow (Retrieval-Augmented Generation Flow) is a system architecture that integrates retrieval (obtaining information from external knowledge bases) and generation (generating content based on retrieval results). RAGFlow has multimodal data processing capabilities, supporting embedded model processing of unstructured data (such as documents, images, and code) to improve retrieval efficiency. It also supports visual document chunking and manual intervention to ensure the accuracy of the parsed results.

[0036] As described in the background section, existing technologies for reviewing requirements documents during software development typically rely on manual review through meetings. This process is not only costly and time-consuming but also prone to overlooking details, affecting the comprehensiveness and accuracy of the review results. Furthermore, differences in the professional backgrounds of reviewers can lead to inconsistent understandings of the requirements documents, further impacting the accuracy of the review outcomes.

[0037] To address the problems of manual review, the inventors conceived of using document review tools to assist in the review of requirements documents. However, common document review tools also have some inherent shortcomings. For example, firstly, there is a disconnect between understanding and action: existing document review tools can understand requirements but cannot autonomously plan review steps; secondly, there is modal isolation: requirements documents typically contain information in multiple modalities such as text, code, and images. Existing document review tools process each modality independently, lacking the ability to jointly analyze multimodal information such as text, images, and code, and are unable to perform cross-modal information review (such as logical consistency checks); thirdly, there is static knowledge retrieval: the knowledge base of existing document review tools is a static knowledge base, unable to learn from each review, resulting in a lagging knowledge base. Therefore, there is an urgent need for an integrated solution that can autonomously reason, operate across modalities, and continuously evolve.

[0038] Building upon this foundation, the inventors conducted a series of research and developments, proposing a solution that deeply integrates ReAct AI Agent and RAGFlow for requirement document review. To better suit the requirement document review scenario of this application, the inventors overcame the limitations of existing ReAct and RAGFlow models. For ReAct, they optimized it for multimodal requirement review scenarios, enhancing its ability to jointly analyze images and code. For RAGFlow, they broke through its limitations in static knowledge retrieval, innovatively integrating it deeply with a multimodal AI Agent to achieve more efficient and accurate requirement document review. The basic idea is as follows: Obtain the review request for the target requirement document sent by the user; use the multimodal artificial intelligence module to parse the target requirement document during the inference phase to determine the key information corresponding to each of the various modal data contained in the target requirement document, as well as at least one action plan involved in the target requirement document; in the action phase, perform knowledge retrieval based on at least one action plan to determine the reference data associated with at least one action plan, and review the target requirement document based on the key information and reference data; generate a review report based on the review results; and send the review report back to the user. This embodiment combines the reasoning and action mechanisms of multimodal ReAct with the multimodal dynamic retrieval of RAGFlow to automatically complete the review of requirement documents. No manual intervention is required, greatly improving efficiency and reducing review costs. Furthermore, during the reasoning phase, ReAct extracts key information from multiple modal data in the requirement document and formulates at least one action plan. This empowers subsequent action phases with the ability to determine where and why to search, guiding RAGFlow to achieve precise retrieval during ReAct's action phase. Through the synergy of these two approaches, a qualitative leap is achieved from "single retrieval information" to "a chain of evidence (i.e., reference data) for precisely retrieving and reviewing action plans." This enables a comprehensive, multi-dimensional review of requirement documents, something that neither a single retrieval nor a single parsing model can accomplish alone. Therefore, this solution also significantly improves the accuracy of review results.

[0039] 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, and 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.

[0040] Figure 1This diagram illustrates a system architecture for a requirement document review system, based on an embodiment of this application. The system architecture may include a user terminal 101 and a server terminal 102. (Alternatively, it may include a server and multiple user terminals; or it may include a server, a first user terminal, and a second user terminal, etc.)

[0041] In this system, the user terminal 101 and the server terminal 102 can establish a connection via a network. The network provides a communication link between the user terminal 101 and the server terminal 102. The network can include various connection types, such as wired, wireless, or fiber optic cables. The user terminal 101 can interact with the server terminal 102 through the network to receive or send messages, etc.

[0042] The user terminal 101 can be a browser, an app (application), a web application such as an H5 (HyperText Markup Language 5) application, a lightweight application (also known as a mini-program), or a cloud application. The user terminal 101 can be deployed on electronic devices and depends on the device to run or on certain apps within the device. Electronic devices can have displays and support information browsing, such as personal mobile terminals like mobile phones, tablets, personal computers, desktop computers, smart speakers, smartwatches, etc. For ease of understanding, Figure 1 The user end is primarily represented by the image of a device. Various other types of applications can also be configured in electronic devices, such as human-computer interaction applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, and social media platform software. Electronic devices can refer to devices used by users that have the computing, internet access, and communication functions required by the user, such as mobile phones, tablets, personal computers, and wearable devices. Electronic devices typically include at least one processing component and at least one storage component. Electronic devices may also include basic configurations such as network interface cards (NICs), I / O (input / output) buses, and audio / video components; this application does not limit this. Optionally, depending on the implementation of the electronic device, it may also include some peripheral devices, such as keyboards, mice, input pens, and printers; this application does not limit this.

[0043] Server 102 may include servers that provide various services, such as a server for backend training that supports the model used on client 101, or a server that processes interactive information sent by client.

[0044] It should be noted that server 102 can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. The server can also be a server in a distributed system, or a server integrated with blockchain. The server can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology.

[0045] It should be noted that, in the embodiments of this application, the review operation of the requirement document is generally performed by the server 102, and the corresponding requirement document review device is generally set in the server 102. However, in other embodiments of this application, the requirement document review method provided in the embodiments of this application can also be jointly performed by the user terminal 101 and the server 102. It should be understood that... Figure 1 The number of client and server instances shown is merely illustrative. Depending on implementation needs, there can be any number of client and server instances.

[0046] The implementation details of the technical solutions in the embodiments of this application are described in detail below.

[0047] Figure 2 A flowchart illustrating a requirement document review method as provided in this application is shown. The technical solution of this embodiment can be executed by a server, such as... Figure 2 As shown, the method may include the following steps:

[0048] S201, Obtain the review request for the target requirement document sent by the user client.

[0049] In this embodiment, the requirements document can be a standardized document that details the software's functions, performance, user interface, and constraints during the software development process, serving as the basis for development, testing, and acceptance. The target requirements document can be the requirements document that needs to be reviewed in this embodiment.

[0050] In the process of internet software development, a requirements document is first written based on the development needs. This document is then reviewed and approved before subsequent operations such as software code development proceed. In this scenario, when a user needs to review a target requirements document, they can initiate a review request from their client to the server (the processing end that performs the requirements document review). For example, the client might provide a requirements document review interface. The user uploads the target requirements document to be reviewed, and the client responds by generating a review request containing the target requirements document or related information (such as a web link to the target requirements document) and sending it to the server. The server then receives the review request for the target requirements document.

[0051] S202, using a multimodal artificial intelligence module to parse the target requirement document during the inference phase to determine the key information corresponding to each of the multiple modal data contained in the target requirement document, as well as at least one action plan involved in the target requirement document; during the action phase, knowledge retrieval is performed based on at least one action plan to determine the reference data associated with at least one action plan, and the target requirement document is reviewed based on the key information and reference data.

[0052] The multimodal AI module can be a ReAct AI Agent built on the ReAct framework, used to perform review tasks on target requirement documents. The Agent in this embodiment can be built based on an AI model. The various models involved in this document can be AI-based language models (LM) or multimodal models (MM), etc. This embodiment does not limit the number of model parameters supported by the model, aiming to meet actual needs.

[0053] In this embodiment, the multimodal AI module performs the task of reviewing the target requirement document in two phases: the reasoning phase and the action phase. The reasoning phase parses the multimodal data in the target requirement document to extract key information corresponding to each modality and to formulate at least one action plan (i.e., an action plan chain) related to the target requirement document. The action phase, based on the results of the reasoning phase (i.e., the key information corresponding to each modality and the formulated at least one action plan), performs knowledge retrieval and document review operations.

[0054] The reasoning phase can be implemented by generating prompts based on the target requirement document. For example, the target requirement document can be used as input data, and then combined with one or more conditions such as operation instructions, role settings, parsing requirements (e.g., constraints, data output requirements), reasoning logic (e.g., the thought chain for parsing multimodal information), and example data to generate prompts. These prompts are then input into the multimodal AI module. Following the prompts, the multimodal AI module first parses the data type (i.e., the modality) corresponding to the data contained in the target requirement document, then sequentially parses the data of each modality in the target requirement document, extracting the key information corresponding to that modality. Finally, based on the extracted key information corresponding to each modality, a phased executable plan, i.e., at least one action plan, is formulated.

[0055] Specifically, when parsing the modalities of the data contained in the target requirement document, corresponding data format types can be pre-defined for different modalities. For example, data in Markdown, Word, and PDF formats belong to the text modality; data in PNG, JPG, and SVG formats belong to the image modality; and data in Python, Java, and JavaScript formats belong to the code modality. During the inference phase, the format types of the data contained in the target requirement document can be parsed first, and the data in the requirement document can be divided according to its modality based on the format type.

[0056] When parsing the data for each modality, the process can involve analyzing the requirements represented by the data, then describing those requirements in natural language to obtain the key information corresponding to each modality. Optionally, this embodiment can use at least one model included in the multimodal artificial intelligence module to parse the data for each modality. For example, it could be a model capable of supporting multimodal data parsing to parse data from multiple modalities, or it could be a dedicated parsing model set up for each modality to perform the parsing of that modality's data; there is no limitation on this.

[0057] When identifying at least one action plan related to the target requirements document, a deeper analysis of the key information corresponding to each of the extracted multimodal data can be performed to identify elements such as objectives, subjects, objects, time, location, constraints, and requirements. Based on these extracted elements, at least one action plan can then be constructed, including: phase divisions, specific tasks, and time phases. For example, an action plan could be to distribute shopping coupons to users who access the XX interface during a specific time period, according to a specific strategy.

[0058] The action phase can be implemented by calling the RAGFlow dynamic retrieval engine tool, using at least one action plan formulated in the inference phase as the index condition to perform dynamic knowledge retrieval, and using the retrieval results corresponding to each action plan as the reference data corresponding to that action plan. Then, based on the key information determined in the inference phase and the reference data of each action plan obtained by RAGFlow dynamic retrieval, the target requirement document is reviewed.

[0059] Specifically, when calling RAGFlow to perform dynamic retrieval operations, it can be for each action plan to retrieve multimodal data such as text, images, and code associated with that action plan from external knowledge bases. For example, it can retrieve implementation code with similar functions to that action plan from platforms such as GitHub and GitLab; search for flowchart / interface templates related to that action plan from internal or public flowchart / interface template databases; and search for document specifications or historical requirement documents related to that action plan from internal or public document libraries.

[0060] When reviewing target requirement documents based on key information and reference data, the review process can involve examining the key information for each modality of data to identify logical problems, such as logical gaps or redundancy. It can also involve reviewing the key information of different modalities to determine if there are conflicts between them, such as requirement conflicts or logical conflicts. Furthermore, it can be based on reference data for each modality to review its key information to determine whether it meets requirements for standardization, rationality, and feasibility. This multi-dimensional and comprehensive approach allows for thorough evaluation of the target requirement documents.

[0061] Optionally, the review results of the target requirement document in this embodiment may include not only any anomalies in the requirement document, but also a description of the reasons for the anomalies and modification suggestions.

[0062] It should be noted that both the reasoning phase and the action phase in this embodiment involve multi-step operations. These multi-step operations can be implemented by one model in the multimodal artificial intelligence module or by multiple models working together; there is no limitation on this.

[0063] S203, Generate an audit report based on the audit results.

[0064] One way to generate a review report based on the review results in this embodiment is to directly add the review results to the corresponding position in the review report template to obtain the review report of the target requirement document.

[0065] Another approach is to quantify the audit results into audit metrics, such as overall score, number of anomalies, and risk level, based on pre-defined evaluation rules. These quantified audit metrics are then added to the audit report template to obtain the audit report for the target requirements document.

[0066] Another implementation method is to: if the review results show anomalies, mark at least one anomaly location in the target requirement document in the review report, along with the corresponding anomaly cause and modification suggestions for each anomaly location. In this embodiment, if the review results show anomalies, the anomaly cause can be analyzed using a multimodal artificial intelligence module, and modification suggestions can be generated. The location of the abnormal data in the target requirement document is taken as the anomaly location. The anomaly cause and modification suggestions corresponding to that anomaly location can be directly marked (e.g., highlighted) in the requirement document, and the anomaly-marked target requirement document is loaded into the review report. Alternatively, one or more anomalies in the review results, along with their corresponding anomaly locations, causes, and modification suggestions, can be organized and visualized in the review report using charts, text, etc. This allows users to intuitively and clearly view the anomalies in the target requirement document through the review report, and the modification suggestions also provide a reference for users to modify the requirement document.

[0067] Optionally, this embodiment can also combine the quantification of the above-mentioned audit indicators with the annotation of abnormal locations, reasons, and modification suggestions to generate an audit report, thereby improving the comprehensiveness of the audit report content.

[0068] For example, Figure 3 The "overall score of 82 points" in the audit report shown is the quantitative indicator based on the audit results; "The overall logical structure of the document is basically clear, but there are inconsistencies in the description of functions before and after, poor feasibility of some modules, and logical redundancy, as detailed below" is the overall description of the audit results; and the types, locations, reasons, and suggestions of the anomalies in the target requirement document are marked in a table.

[0069] S204, the audit report will be sent back to the user.

[0070] After generating the review report, it can be sent back to the client that sent the review request. This can be done via email, instant messaging, or an internal platform. If the review report indicates approval, the corresponding client can continue with subsequent software development. If the report indicates disapproval, the client can modify the target requirement document based on the report and then resubmit the review request to the processing end based on the revised document. This supports iterative review of the target requirement document.

[0071] Optionally, this embodiment provides a system for reviewing requirements documents, which not only supports sending the generated review report back to the user, but also supports exporting in multiple formats, such as PDF, Markdown, and JSON. Furthermore, it can provide an API (Application Programming Interface) for other systems to call.

[0072] In this embodiment, a review request for a target requirement document sent by the user terminal is obtained. A multimodal artificial intelligence module parses the target requirement document during the inference phase to determine the key information corresponding to each of the various modal data contained in the document, as well as at least one action plan involved in the document. During the action phase, knowledge retrieval is performed based on at least one action plan to determine reference data associated with it. The target requirement document is then reviewed based on the key information and reference data. A review report is generated based on the review results and sent back to the user terminal. This embodiment combines the inference and action mechanisms of multimodal ReAct with the multimodal dynamic retrieval of RAGFlow to automatically complete the review task of requirement documents. No manual intervention is required, greatly improving review efficiency and reducing review costs. Furthermore, during the inference phase, ReAct extracts key information from multiple modalities of data in the requirements document and formulates at least one action plan. This empowers subsequent action phases with the ability to determine where and why to search, guiding RAGFlow to achieve precise retrieval during ReAct's action phase. Through the synergy of these two approaches, a qualitative leap is achieved from "single retrieval information" to "the evidence chain (i.e., reference data) for precise retrieval and review of the action plan." This enables a comprehensive and multi-dimensional review of the requirements document, something that neither a single retrieval nor a single parsing model can accomplish alone. Therefore, this solution can also greatly improve the accuracy of the review results.

[0073] In some embodiments, considering that multimodal data parsing is a complex task, implementing it through a single intelligent model can easily lead to model illusion problems. To avoid this problem and ensure the accuracy of the parsing results, this embodiment can also deploy a natural language parsing model, an object detection model, and a syntax parsing model in the multimodal artificial intelligence module. The natural language parsing model is used to perform semantic recognition on the text data in the target requirement document to extract the functional elements of the text data. The object detection model is used to perform object recognition on the flowcharts and / or interface diagrams in the target requirement document to extract node relationship information in the flowcharts and / or element change information in the interface diagrams. The syntax parsing model is used to parse the code in the target requirement document to extract interface call information and function logic information.

[0074] The natural language parsing model can be a model that supports semantic parsing of natural language descriptive text, such as a Natural Language Processing (NLP) model, specifically the BERT (Bidirectional Encoder Representation from Transformers) model within NLP. The natural language parsing model is used to perform semantic recognition on the text data in the target requirement document, and based on the semantic recognition results, functional requirements related to the document plan, document functions, and technical constraints are extracted from the text data as key information corresponding to the text data.

[0075] The object detection model can be a model used for object detection in images, such as a model built based on OCR (Optical Character Recognition) or YOLO (You Only Look Once) algorithms. Since the images in the requirements document mainly include flowcharts and interface diagrams, this example uses an object detection model to identify the nodes and relationships between them in the flowchart when the requirements document contains a flowchart, as node relationship information (i.e., key information of the flowchart). When the requirements document contains interface diagrams, these diagrams usually indicate changes to elements within the interface. For example, if the interface diagram is a newly added interface diagram for the software product, it will be marked with a note indicating the new interface diagram; if it is an existing interface diagram for the software product, it will be marked with newly added elements. This embodiment can use an object detection model to identify changed elements in the interface image. For newly added interface diagrams, all relevant information about the elements they contain (such as element identifiers, locations, and functional descriptions) can be identified as element change information (i.e., key information of the interface diagram). For existing interface diagrams, relevant information about newly added elements can be identified as element change information. Optionally, in this embodiment, the target detection models used to identify the flowchart and the interface diagram can be the same or different.

[0076] The syntax parsing model can be a syntax parser (such as a Tree-sitter) that performs syntax analysis on code. In this embodiment, the syntax parsing model can be used to perform syntax parsing on the code in the target requirements document, and the interface call information and function logic information of the code can be extracted as key information of the code based on the parsing results.

[0077] This embodiment addresses three different data modalities: text data, image data, and code data. It employs multiple models working collaboratively to extract key data, leveraging the strengths of different models to achieve more efficient, accurate, and flexible extraction of key information. This breaks through the limitations of a single model, refining the division of labor and ensuring the accuracy of key information extraction. It should be noted that the target requirement document can be any combination of text data, image data, and code data; for example, it may contain only text and image data, excluding code data. Therefore, this embodiment can employ the corresponding model for key information extraction based on the actual data modality contained in the target requirement document.

[0078] In some embodiments, another way to use RAGFlow to retrieve reference data in this embodiment is as follows: during the action phase, for any action plan, retrieve historical entity relationship description information associated with the action plan in the knowledge graph; extract multiple modal data associated with the action plan from the historical requirement documents corresponding to the historical entity relationship description information, and use them as reference data associated with the action plan.

[0079] In this embodiment, the knowledge graph can be constructed based on historically approved requirement documents. For example, entity information and relationship information between entities can be extracted from historically approved requirement documents. Nodes in the knowledge graph represent the entity information of the requirement documents, and edges represent the relationship information between entities. When retrieving reference data, this example can retrieve the entity information and relationship information associated with each action plan from the knowledge graph as historical entity relationship description information. Based on this historical entity relationship description information, historical requirement documents are located, and then the corresponding text data, image data, and code data are retrieved from these historical requirement documents as reference data associated with the action plan. This embodiment constructs a knowledge graph corresponding to historical requirement documents, facilitating quick and accurate retrieval of parameter data associated with each action plan. This assists subsequent document review operations, allowing the requirement document review process to no longer focus solely on the current target requirement document but also incorporate related historical documents, improving the comprehensiveness and accuracy of requirement document review.

[0080] In some embodiments, in scenarios where dynamic knowledge retrieval is performed using a knowledge graph, this embodiment may further include: if the review report shows that the review has passed, then extracting the target entity relationship description information of the target requirement document from the key information; and updating the knowledge graph based on the target entity relationship description information. Specifically, this embodiment can set corresponding document states for the target requirement document, such as being in an unreviewed state (draft), a reviewed and approved state (published), and a reviewed and approved state (revised). During the review of the target requirement document, the status of the target requirement document is detected and updated in real time. After the review of the target requirement document is completed, it is detected whether the status of the target requirement document is a reviewed and approved state (revised). If so, entity information (such as events, platforms, target users, objects, etc.) is extracted from the key information corresponding to each of the multimodal data, and the relationship information between entities (such as sending events from platform 1) is used as the target entity relationship description information of the target requirement document. Then, the node information in the knowledge graph is updated using the entity information in the target entity relationship description information, and the edge information between nodes in the knowledge graph is updated using the relationship information between entities recorded in the target entity relationship description information. Since the key information in this embodiment is the key information corresponding to each of the multimodal data, this embodiment can map the document data, image data, and entity and relationship information corresponding to the code in the target requirement document to the knowledge graph. That is, the approved requirement document of this application is used as the input of the knowledge graph, forming a closed-loop learning system. The ReAct AI Agent uses the knowledge retrieved by RAGFlow to make decisions, and the valuable new knowledge generated after the decision (i.e., target entity relationship description information) is absorbed by the RAGFlow of subsequent review operations. This allows the system's knowledge graph to automatically grow and update in real time with each review task, and its intelligence level continues to iterate, forming a "flywheel effect" that gets smarter the more it is used.

[0081] In some embodiments, when reviewing a target requirement document based on key information and reference data, this embodiment may include: reviewing the logical consistency between key information in different modal data of the requirement document; reviewing the standardization of key information based on reference data; and reviewing the feasibility of at least one action plan based on the matching degree between key information and reference data.

[0082] Specifically, when conducting logical consistency audits on data from different modalities, the key information of each modality can be categorized according to requirements. The logical consistency of key information within the same requirement across different modalities can be reviewed. For example, for each requirement, the key information in the text and flowchart can be compared for consistency to verify the consistency between the text's requirement description and the flowchart's logic. For instance, if the text requirement describes "users are redirected to the homepage after logging in," but the flowchart does not include a "homepage" node, then the text's requirement description is inconsistent with the flowchart's logic. Similarly, the key information in the text and code can be compared for consistency to verify the match between the text's requirement description and the code's implementation logic. For instance, if the text requirement describes "support for multilingual switching," but the code does not include language switching logic, then the text's requirement description does not match the code's implementation logic. Finally, the key information in the flowchart and code can be compared for consistency to verify the consistency between the flowchart's logic and the code's logic. For instance, if the flowchart shows updates to real-time data, but the code uses a static data source, then the flowchart's logic is inconsistent with the code's logic.

[0083] In addition, parameter data can be used as a benchmark to review whether text data conforms to design specifications, interface specifications, etc.; whether image data conforms to the template requirements of flowcharts and interface diagrams; and whether code conforms to programming standards. Furthermore, when the reference data includes multimodal data from historical requirement documents retrieved based on knowledge graphs, for each action plan, the matching degree between the multimodal data associated with that action plan in the historical requirement document and the multimodal data associated with that action plan in the target requirement document can be compared to determine whether at least one action plan involved in the target requirement document is feasible. For example, a high matching degree indicates the action plan is feasible; otherwise, it is not feasible. This embodiment can achieve cross-modal conflict detection, standardization detection, and functional feasibility detection of multimodal data in target requirement documents. It comprehensively examines target requirement documents from multiple dimensions.

[0084] In some embodiments, to further improve the accuracy of the review results, this embodiment may also introduce a dynamic evaluation mechanism for the action plan generated in the reasoning stage and / or the reference data retrieved in the action stage, so that the server can flexibly adjust the subsequent review strategy like a human expert.

[0085] Optionally, for action plans, this embodiment can introduce a scoring mechanism similar to priority: if the target requirement document involves multiple action plans, then for each action plan, predict at least one indicator value among the following: plan value, plan feasibility, and risk index. Based on the at least one indicator value and its corresponding weight parameters, determine the indicator score of the action plan. Based on the indicator scores of multiple action plans, select the target action plan from among them. Correspondingly, during the action phase, perform knowledge retrieval based on the target action plan to determine reference data associated with the target action plan. Here, plan value can characterize the benefits that the action plan brings to the application. Plan feasibility can characterize the difficulty coefficient of plan implementation. The risk index can characterize the risk index that needs to be undertaken to implement the action plan.

[0086] Specifically, when there are multiple action plans, this embodiment can use an intelligent scoring model (which may or may not belong to the multimodal artificial intelligence module) to predict at least one of the following indicators: plan value, plan feasibility, and risk index, based on each action plan. Then, the indicator values ​​and their corresponding weight parameters are weighted and summed according to the following formula to obtain the indicator score corresponding to the action plan.

[0087] Indicator score = α × Plan value + β × Plan feasibility + γ × Risk index;

[0088] Where α is the weight parameter corresponding to the plan value; β is the weight parameter corresponding to the plan feasibility; and γ is the weight parameter corresponding to the risk index.

[0089] Then, based on the indicator scores from high to low, select the action plans with scores greater than the preset score value or the preset number of top-ranked action plans as the target action plans. Subsequently, knowledge retrieval operations are performed only on the target action plans for the action phase.

[0090] This embodiment introduces dynamic evaluation of action plans, selecting those with high index scores for subsequent knowledge retrieval, rather than mechanically performing dynamic retrieval on all action plans. This avoids the problem of insufficient confidence or conflicts in reference data retrieved based on a low-scoring action plan. This embodiment applies this decision optimization capability based on real-time feedback scoring indicators to a scenario where ReAct's inference capabilities and RAGFlow's real-time retrieval capabilities are deeply integrated, greatly improving the reliability and efficiency of the review process.

[0091] In some embodiments, this embodiment may further include: determining whether the target requirement document has historical review data; if so, adjusting the weight parameters corresponding to at least one indicator value based on the historical review data. Specifically, checking whether the target requirement document has historical review data; if not, it indicates that the target requirement document is being reviewed for the first time, and in this case, the weight parameters corresponding to each indicator value do not need to be adjusted, and the indicator score can be calculated directly using the default weight parameters corresponding to each indicator value. If so, it indicates that the target requirement document has been reviewed before and there are anomalies; in this case, the historical anomalies corresponding to the target requirement document during the previous review can be located based on the historical review data, and the weight parameters corresponding to at least one indicator value can be adjusted based on the historical anomalies. For example, if the historical anomaly is that the action plan has a feasibility problem, the weight parameter value of the plan feasibility can be increased, and the weight parameters corresponding to the plan value and risk index can be decreased; if the historical anomaly is that the key information has a standardization problem, the weight parameter value of the risk index can be increased, and the weight parameters corresponding to the plan value and plan feasibility can be decreased.

[0092] This embodiment can dynamically optimize the weight parameters of plan feasibility, plan value, and risk index by combining historical review data of target requirement documents. It can achieve targeted selection of target action plans to guide subsequent dynamic knowledge retrieval operations, thereby improving the relevance of reference data retrieval and ensuring the accuracy of review results.

[0093] Optionally, a compliance-based risk assessment mechanism is introduced for the reference data obtained through dynamic knowledge retrieval: a risk assessment is performed on the reference data associated with at least one action plan; based on key information and the reference data that has passed the risk assessment, the target requirement document is reviewed. Specifically, this can be done using an intelligent assessment model (which may or may not belong to a multimodal artificial intelligence module) to perform a risk assessment on the reference data retrieved for each action plan, such as reviewing whether the reference data has any risk of violation and whether it is truly relevant to the action plan. Subsequently, the target requirement document is reviewed based on the reference data that has passed the risk assessment and the key information. This embodiment introduces dynamic assessment of the retrieved reference data, selecting the reference data that has passed the risk assessment to perform the subsequent review operation of the target requirement document, rather than mechanically performing the subsequent review operation of the target requirement document for all retrieval results (i.e., all reference data). This avoids conflicts that may arise when reviewing the target requirement document based on the reference data due to the existence of risks, thus affecting the confidence of the review results. This greatly improves the reliability of the review results.

[0094] In a practical application scenario, this application provides a preferred implementation method for efficiently and accurately reviewing target requirement documents, such as... Figure 4As shown. When a user needs to review a target requirement document, they will input the target requirement document, such as initiating a review request for the target requirement document from the user's client to the server (S401). The server will then call the multimodal ReAct AIAgent to review the target requirement document through two phases: reasoning and action (S402).

[0095] In the reasoning phase, multimodal requirements analysis (S403) can be performed on the target requirements document. For example, the data format types of each data in the target requirements document can be analyzed to determine the corresponding modality. Different models can be used for requirements analysis for different modalities to extract key information corresponding to each modality. Then, the determined key information can be analyzed in greater depth to formulate multiple action plans. The formulated multiple action plans need to be scored through a dynamic evaluation module (S404), which predicts the value of the action plan, the feasibility of the plan, and at least one indicator value of the risk index. Based on the at least one indicator value and its corresponding weight parameters, the indicator score of the action plan is determined. Based on the scoring results, the target action plan is selected from the multiple action plans.

[0096] Based on the approved target action plan, dynamic retrieval operations are performed in the subsequent action phase. This involves using RAGFlow to perform dynamic knowledge retrieval based on the target action plan (S405). For example, this includes retrieving industry standards and norms from the industry standard library (i.e., data standard retrieval); retrieving implementation code with similar functions to the target action plan from platforms such as GitHub and GitLab (i.e., code repository retrieval); searching for flowchart / interface templates related to the target action plan from internal or public flowchart / interface template databases (i.e., diagram template retrieval); and searching for requirement documents related to the target action plan from the knowledge graph (i.e., historical requirement document retrieval).

[0097] The retrieval results (i.e., reference data) of dynamic knowledge retrieval also need to undergo dynamic evaluation (S406), that is, risk assessment is performed on the reference data associated with the target action plan, and cross-modal detection is performed based on the key information determined in the reasoning stage and the reference data that has passed the risk assessment (S407). For example, the logical consistency between key information in different modal data in the requirements document is reviewed; the standardization of key information is reviewed based on the reference data; and the feasibility of at least one action plan is reviewed based on the matching degree between the key information and the reference data. If there are anomalies in the review results, at least one abnormal position in the target requirements document is marked, along with the corresponding abnormality reason and modification suggestion (i.e., conflict marker S408), and an review report S409 is generated and output as review report S410.

[0098] This embodiment proposes a method for dynamically reviewing requirement documents for internet software based on a deep fusion technology of multimodal ReAct AI Agent and RAGFlow. By leveraging ReAct's reasoning and action capabilities and RAGFlow's multimodal dynamic knowledge retrieval capabilities, semantic verification, compliance and logical checks of requirements, as well as feasibility prediction, are achieved. This addresses the shortcomings of existing requirement document review tools in areas such as multimodal data processing capabilities, dynamic knowledge update mechanisms, and cross-modal consistency verification. By introducing a collaborative mechanism between the multimodal ReAct AI Agent and the RAGFlow dynamic retrieval engine, an intelligent and automated requirement document review method is constructed.

[0099] This embodiment achieves deep integration of multimodal ReAct and RAGFlow, combining ReAct's reasoning and action mechanisms with RAGFlow's multimodal dynamic retrieval for the first time, enabling closed-loop decision-making in requirement document review. It constructs a cross-modal knowledge graph, specifically a dynamic knowledge graph spanning text, images, and code, supporting joint analysis of multimodal data and improving the comprehensiveness and timeliness of retrieval results. Multimodal conflict detection is implemented to address the consistency verification issue of multimodal data in requirement documents. Dynamic knowledge updates and feedback are introduced: RAGFlow multimodal retrieval is triggered through ReAct's action module, supporting real-time knowledge base updates and strategy adjustments.

[0100] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0101] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear in this document, or may be executed in parallel. The sequence numbers are merely used to distinguish different operations, and the sequence numbers themselves do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should also be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0102] Figure 5 A schematic diagram of a requirements document review device provided for an exemplary embodiment of this application, the device comprising:

[0103] The request retrieval unit 501 is used to retrieve the review request for the target requirement document sent by the user client.

[0104] The intelligent parsing unit 502 is used to parse the target requirement document in the inference stage using a multimodal artificial intelligence module to determine the key information corresponding to each of the multiple modal data contained in the target requirement document, as well as at least one action plan involved in the target requirement document; in the action stage, it performs knowledge retrieval based on the at least one action plan to determine reference data associated with the at least one action plan, and reviews the target requirement document based on the key information and the reference data.

[0105] The report generation unit 503 is used to generate an audit report based on the audit results;

[0106] The report sending unit 504 is used to send the audit report back to the user terminal.

[0107] In some embodiments, the apparatus further includes: a scoring unit, configured to, if the number of action plans involved in the target requirement document is multiple, predict at least one of the following indicators for each action plan: plan value, plan feasibility, and risk index, and determine the indicator score of the action plan based on the at least one indicator value and its corresponding weight parameters;

[0108] The plan screening unit is used to screen target action plans from the multiple action plans based on the indicator scores of the multiple action plans;

[0109] During the action phase, the intelligent analysis unit 502 is specifically used to perform knowledge retrieval based on the target action plan in order to determine reference data associated with the target action plan.

[0110] In some embodiments, the apparatus further includes a weight adjustment unit, configured to determine whether the target requirement document has historical review data, and if so, to adjust the weight parameter corresponding to at least one indicator value based on the historical review data.

[0111] In some embodiments, the intelligent parsing unit 502 is further configured during the action phase to retrieve historical entity relationship description information associated with any action plan from a knowledge graph; the nodes in the knowledge graph represent entity information of a requirement document, and the edges represent relationship information between entities; and extract multiple modal data associated with the action plan from the historical requirement document corresponding to the historical entity relationship description information as reference data associated with the action plan.

[0112] In some embodiments, the apparatus further includes: a knowledge graph updating unit, configured to extract target entity relationship description information of the target requirement document from the key information if the target requirement document passes the review; and update the knowledge graph according to the target entity relationship description information.

[0113] In some embodiments, when the intelligent parsing unit 502 reviews the target requirement document, it is specifically used to perform risk assessment on the reference data associated with each of at least one action plan; and to review the target requirement document based on the key information and the reference data that has passed the risk assessment.

[0114] In some embodiments, when the intelligent parsing unit 502 reviews the target requirement document, it is also specifically used to review the logical consistency between key information of different modal data in the requirement document; review the standardization of the key information based on the reference data; and review the feasibility of the at least one action plan based on the matching degree between the key information and the reference data.

[0115] In some embodiments, the multimodal artificial intelligence module includes: a natural language parsing model, an object detection model, and a syntax parsing model; the intelligent parsing unit 502 is further specifically used in the inference phase to perform at least one of the following: using the natural language parsing model to perform semantic recognition on the text data in the target requirement document to extract the functional elements of the text data; using the object detection model to perform object recognition on the flowcharts and / or interface diagrams in the target requirement document to extract node relationship information in the flowcharts and / or element change information in the interface diagrams; using the syntax parsing model to parse the code in the target requirement document to extract interface call information and function logic information of the code.

[0116] In some embodiments, the report generation unit 503 is specifically used to mark at least one abnormal location of the target requirement document in the audit report if the audit result is abnormal, as well as the abnormal reason and modification suggestion corresponding to each of the at least one abnormal location.

[0117] Figure 5 The aforementioned requirement document review device can perform... Figure 2 The implementation principle and technical effects of the requirement document review method described in the illustrated embodiment will not be repeated here. The specific methods by which each unit of the requirement document review device in the above embodiments performs its operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0118] Figure 6 This is a schematic diagram of the structure of one embodiment of a computing device provided in this application. Figure 6 As shown, in practice, the computing device may include a storage component 601 and a processing component 602.

[0119] Storage component 601 is used to store computer programs and can be configured to store various other data to support operation on a computing device. Examples of this data include instructions for any application or method used to operate on the computing device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0120] Processing component 602, coupled to storage component 601, is used to execute computer programs in storage component 601 for implementing, etc. Figure 2 The method for reviewing the requirements document is shown.

[0121] Furthermore, such as Figure 6 As shown, the computing device may also include other components such as a communication component 603, a display component 604, a power supply component 605, and an audio component 606. Figure 6 The diagram only shows some components and does not mean that the device includes only these components. Figure 6 The components shown. Additionally... Figure 6 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the computing device. The computing device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT (Internet of Things) device, or a server-side device such as a conventional server, cloud server, or server array. If the computing device in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 6 The components within the dashed box; if the computing device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., then it may not include... Figure 6 The component within the dashed box.

[0122] The processing component described above includes one or more processors to execute computer instructions to complete all or part of the steps in the method described above. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for performing the method described above.

[0123] The aforementioned storage components can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0124] The aforementioned communication component is configured to facilitate wired or wireless communication between the device housing the communication component and other devices. The device housing the communication component can access wireless networks based on communication standards, such as mobile communication networks, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0125] The aforementioned display components may include a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0126] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0127] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0128] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0129] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0130] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0131] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0132] Finally, it should be noted that the above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for reviewing requirements documents, characterized in that, include: Obtain the review request sent by the user client for the document targeting the requirements; The target requirement document is parsed during the inference phase using a multimodal artificial intelligence module to determine the key information corresponding to each of the multiple modal data contained in the target requirement document, as well as at least one action plan involved in the target requirement document. During the action phase, knowledge retrieval is performed based on the at least one action plan to identify reference data associated with the at least one action plan, and the target requirement document is reviewed based on the key information and the reference data. Based on the audit results, generate an audit report; The audit report will be sent back to the user.

2. The method according to claim 1, characterized in that, Also includes: If the target requirement document involves multiple action plans, then for each action plan, predict at least one indicator value among the plan value, plan feasibility, and risk index corresponding to the action plan, and determine the indicator score of the action plan based on the at least one indicator value and its corresponding weight parameters. Based on the indicator scores of multiple action plans, select the target action plan from the multiple action plans; The knowledge retrieval performed during the action phase based on the at least one action plan to determine reference data associated with the at least one action plan includes: During the action phase, knowledge retrieval is performed based on the target action plan to identify reference data associated with the target action plan.

3. The method according to claim 2, characterized in that, Before determining the priority of the action plan based on the at least one indicator value and its corresponding weight parameter, the method further includes: Determine whether the target requirement document has historical review data. If it does, adjust the weight parameter corresponding to at least one indicator value based on the historical review data.

4. The method according to claim 1, characterized in that, The knowledge retrieval performed during the action phase based on the at least one action plan to determine reference data associated with the at least one action plan includes: During the action phase, for any action plan, historical entity relationship description information associated with the action plan is retrieved from the knowledge graph; the nodes in the knowledge graph represent entity information of the requirement document, and the edges represent relationship information between entities; Extract various modal data associated with the action plan from the historical requirement documents corresponding to the historical entity relationship description information, and use them as reference data associated with the action plan.

5. The method according to claim 4, characterized in that, Also includes: If the target requirement document is approved, the target entity relationship description information of the target requirement document is extracted from the key information; The knowledge graph is updated based on the target entity relationship description information.

6. The method according to claim 1, characterized in that, The review of the target requirement document based on the key information and the reference data includes: Conduct a risk assessment of the reference data associated with at least one action plan; Based on the aforementioned key information and the reference data from the successful risk assessment, the target requirement document was reviewed.

7. The method according to claim 1, characterized in that, The review of the target requirement document based on the key information and the reference data includes at least one of the following: Review the logical consistency between key information in the different modal data of the requirements document; Based on the aforementioned reference data, the standardization of the key information was reviewed; and, The feasibility of the at least one action plan is reviewed based on the degree of matching between the key information and the reference data.

8. The method according to claim 1, characterized in that, The multimodal artificial intelligence module includes: a natural language parsing model, an object detection model, and a syntax parsing model; The step of using a multimodal artificial intelligence module to parse the target requirement document during the inference phase to determine the key information corresponding to each of the various modal data contained in the target requirement document includes at least one of the following: The natural language parsing model is used to perform semantic recognition on the text data in the target requirement document in order to extract the functional elements of the text data; The target detection model is used to identify targets in the flowcharts and / or interface diagrams in the target requirement document, so as to extract node relationship information in the flowcharts and / or element change information in the interface diagrams. The code in the target requirements document is parsed using the syntax parsing model to extract the interface call information and function logic information of the code.

9. The method according to claim 1, characterized in that, The process of generating an audit report based on the audit results includes: If the audit results are abnormal, at least one abnormal location in the target requirement document will be marked in the audit report, along with the corresponding reason for the abnormality and modification suggestions for each of the at least one abnormal location.

10. A device for reviewing requirements documents, characterized in that, include: The request retrieval unit is used to retrieve the review request sent by the user client for the target requirement document; The intelligent parsing unit is used to parse the target requirement document during the inference phase using a multimodal artificial intelligence module, so as to determine the key information corresponding to each of the multiple modal data contained in the target requirement document, as well as at least one action plan involved in the target requirement document. During the action phase, knowledge retrieval is performed based on the at least one action plan to identify reference data associated with the at least one action plan, and the target requirement document is reviewed based on the key information and the reference data. The report generation unit is used to generate an audit report based on the audit results; The report sending unit is used to send the audit report back to the user terminal.

11. A computing device, characterized in that, This includes processing components and storage components; The storage component stores a computer program; the computer program is invoked and executed by the processing component to implement the method for reviewing requirement documents as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by the processing component, implements the method for reviewing requirement documents as described in any one of claims 1-9.

13. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processing component, implement the method for reviewing a requirements document as described in any one of claims 1-9.

Images