Document review method and apparatus, storage medium, computer program product

Abstract

The application provides a document review method and device, a storage medium and a computer program product. The method comprises the following steps: performing semantic decomposition on a product requirement document (PRD) to divide the PRD into a plurality of initial function units; wherein each initial function unit at least contains the following type information: a document segment and a source location related to the PRD, a business main category and a confidence degree to which the initial function unit belongs, and a subdivision label for identifying a verifiable constraint condition across business categories; for each initial function unit, knowledge enhancement and correction are performed through term similarity retrieval in a term library and knowledge similarity retrieval in a knowledge base, so that each initial function unit is updated to a target function unit; for each target function unit, rule entry matching is performed in a rule library, and review is performed based on the matched rule entries to generate a review conclusion; and a review report of the PRD is generated based on the review conclusions of different target function units.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a document review method and apparatus, storage medium, and computer program product. Background Technology

[0002] In complex software development, Product Requirements Documents (PRDs) must accurately describe detailed business rules such as multi-region, multi-tenant, billing policies, and access control, requiring extremely high levels of completeness, consistency, and executability. To improve review efficiency and quality, the industry is gradually introducing intelligent review technologies, utilizing natural language processing and knowledge bases to assist in automated verification.

[0003] Existing PRD document review schemes typically employ review mechanisms based on rule templates, FPA or function type, or semantic extraction based on domain dictionaries and dependency syntax. These schemes often suffer from the following problems: business constraints are difficult to express in a structured way and be reliably cited; classification and retrieval mechanisms struggle to accurately match appropriate check items and criteria in complex scenarios; and review results often remain at the existence / statistic level without a feasible and comprehensive path, resulting in low review efficiency and accuracy of existing document review schemes. Summary of the Invention

[0004] This application provides a document review method and apparatus, storage medium, and computer program product.

[0005] This application provides a document review method, including: Semantic decomposition of the Product Requirements Document (PRD) is performed, dividing it into multiple initial functional units. Each initial functional unit contains at least the following types of information: relevant document fragments in the PRD and their source locations, the main business category to which they belong and their confidence level, and detailed labels that identify verifiable constraints across business categories. For each initial functional unit, knowledge enhancement and correction are performed by performing term similarity searches in the terminology database and knowledge similarity searches in the knowledge base, so that each initial functional unit is updated to a target functional unit. For each target functional unit, rule entries are matched in the rule base, and reviews are conducted based on the matched rule entries to generate review conclusions. Based on the review conclusions of different target functional units, a review report of the PRD is generated.

[0006] This application provides a document review apparatus, including: a processor, a memory, and a communication bus; The communication bus is used to realize the communication connection between the processor and the memory; The processor is used to execute one or more computer programs stored in the memory to implement the document review method described above.

[0007] This application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described document review method.

[0008] This application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described document review method.

[0009] This application provides a document review method, apparatus, storage medium, and computer program product. The method includes: semantically decomposing a Document Review Document (PRD) into multiple initial functional units; each initial functional unit includes at least the following types of information: related document fragments in the PRD and their source locations, their respective business main categories and their confidence levels, and detailed labels identifying verifiable constraints across business categories; for each initial functional unit, performing knowledge enhancement and correction by conducting terminology similarity searches in a terminology database and knowledge similarity searches in a knowledge base, so that each initial functional unit is updated to a target functional unit; for each target functional unit, performing rule entry matching in a rule base, reviewing based on the matched rule entries, and generating review conclusions; and generating a PRD review report based on the review conclusions of different target functional units. The technical solution provided by this application, through semantic decomposition and knowledge enhancement, accurately maps the PRD into target functional units with categories and labels, and reviews the target functional units based on a rule-matching review mechanism, realizing the structured reference of business rules, significantly improving review efficiency and accuracy. Attached Figure Description

[0010] Figure 1 A schematic diagram of a PRD review process is provided for an embodiment of this application; Figure 2 A flowchart illustrating a document review method provided in an embodiment of this application; Figure 3 A flowchart illustrating an initial functional unit generation method provided in an embodiment of this application; Figure 4 A flowchart illustrating a method for generating a target functional unit provided in an embodiment of this application; Figure 5 A flowchart illustrating a target functional unit review method provided in an embodiment of this application; Figure 6 A flowchart illustrating a candidate rule entry processing method provided in an embodiment of this application; Figure 7 A schematic diagram of the structure of a document review device provided in this application embodiment. Figure 1 ; Figure 8 A schematic diagram of the structure of a document review device provided in this application embodiment. Figure 2 . Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0012] The technical solutions of this application and how they solve the aforementioned technical problems will be described in detail below through embodiments and in conjunction with the accompanying drawings. The embodiments below can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0013] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0014] This application provides a document review method, which is implemented through a document review device. The document review device can be any electronic device such as a mobile phone or computer, and this application does not limit it.

[0015] The document review methodology provided in this application embeds an interpretable "knowledge-tag-rule" triple mechanism throughout the complete review process, ensuring that every step from text to conclusion is based on verifiable evidence. Starting from the full PRD (Proofread Document), it sequentially completes the semantic decomposition process, knowledge enhancement and correction process, checkpoint matching and hierarchical evaluation, and guides the supplementation of missing information through interactive dialogue when necessary, ultimately generating structured review results and application-oriented document output. See also Figure 1 This mainly involves the following: 1. Semantic decomposition: Under the constraints of category enumeration and a whitelist of detailed tags, the original PRD document is divided into several reasonably granular "initial functional units." The "main business category" refers to a coarse-grained classification of the business scope of the functional unit, serving to provide routing and scope for subsequent inspection strategies. The "detailed tags" are used to characterize verifiable points or modifying conditions across categories, selected only from a uniformly maintained whitelist to ensure consistent comparability across different documents. Under these constraints, a main business category and detailed tags are provided for each unit.

[0016] 2. Knowledge Enhancement and Correction: Search the terminology and knowledge base, make the minimum necessary corrections and additions to the aforementioned initial functional units (including corrections and additions to the main business categories and subcategories), and unify the tags into the whitelist system for cross-document reuse, so that each initial functional unit is updated to a target functional unit.

[0017] 3. Item matching and stratified assessment: Based on the main business category and sub-label of the target functional unit, match the key inspection items (rules) for each target functional unit, and form an actionable review checklist and hierarchical conclusions (such as complete / to be supplemented / omitted).

[0018] 4. Interactively refine and compile the results to output the final document: When the review conclusions reveal information gaps or inconsistencies, clear prompts and supplementary suggestions are provided through interactive dialogue to encourage iterative improvement of the document. Finally, the structured results are compiled into a unified review report and document generation result, including conclusions, basis, and an actionable improvement checklist, making it easy for users to use directly.

[0019] Based on the above, the document review method provided in this application is described in detail below.

[0020] Figure 2 This is a flowchart illustrating a document review method provided in an embodiment of this application. Figure 2 As shown in the embodiments of this application, the document review method mainly includes the following steps: S101. Perform semantic decomposition on the PRD and divide it into multiple initial functional units; each initial functional unit shall contain at least the following types of information: relevant document fragments in the PRD and their source location, the main business category to which they belong and their confidence level, and sub-labels that identify verifiable constraints across business categories.

[0021] In the embodiments of this application, the document review device may first perform semantic decomposition on the PRD, dividing it into multiple initial functional units.

[0022] It should be noted that, in the embodiments of this application, the initial functional unit is used to carry module-level structured information, which typically includes fields such as "title, core description, corresponding original text fragment, main business category and its confidence level, sub-label, remarks and prompts, source citations", to ensure a traceable closed loop of "review conclusion - original text evidence - inspection rules".

[0023] It should be noted that, in the embodiments of this application, the functional unit is the smallest carrier of document review. The initial functional unit and the target functional unit formed by subsequent updates of the initial functional unit are the specific objects of the functional unit at different stages. The functional unit design is as follows: 1. Purpose: To convey "what function this original text describes, how we classify and examine it, and where the evidence is."

[0024] 2. What is needed: Source location and original text excerpt are used for verification (e.g., source = lines 12-34 of the current document; original text = "...users can create resource A...").

[0025] The business classification is based on "business main category (category) + confidence (confidence)", for example, finalCategory = identity and permissions, =0.82.

[0026] The number of unified tags in the unified whitelist is ≤5. They can cross categories, cannot be created independently, and drive rule matching (e.g., unified tag = fee item, account difference).

[0027] Optional additions: notes, i.e., non-label contextual information; evidence chain, including the reason for the change and the evidence reference; status level; dependency failure flag, which indicates that failure to meet prerequisite dependencies will lead to degradation.

[0028] 3. Design effect: Traceability: Any category and label can be traced back to the original text and the reasons for the changes; Reusability: A unified whitelist and grouped views ensure consistency in tags across different documents; Executability: Provides stable input (category + unifiedTags) for rule matching.

[0029] It should be noted that, in the embodiments of this application, each functional unit obtained by semantically decomposing the PRD text is an "initial functional unit". The semantic decomposition of the PRD is completed by a constrained large language model (LLM). The process adopts constrained prompts and whitelist constraints, and the output granularity is consistent with the expression, which facilitates subsequent knowledge enhancement and rule matching.

[0030] In the embodiments of this application, see Figure 3The document review device performs semantic decomposition on the PRD, dividing it into multiple initial functional units. This includes: based on constraint prompts, driving the large language model to split the PRD into multiple functional arrays according to functional semantics; each functional array includes at least the following types of information: related document fragments in the PRD and their source locations, the business main category to which it belongs and its confidence level, and sub-labels identifying verifiable constraints across business categories; performing structural verification and whitelist verification on the multiple functional arrays; structural verification includes verifying that the functional arrays have a set array structure, and whitelist verification includes verifying that the business main category of the functional arrays belongs to a preset selectable business category, and that the sub-labels belong to a preset label whitelist; if the verification passes, each functional array in the multiple functional arrays is determined as an initial functional unit, resulting in multiple initial functional units; if the verification fails, based on constraint prompts, the large language model is driven again to split and verify the PRD into functional arrays according to functional semantics until multiple initial functional units are obtained.

[0031] It should be noted that, in the embodiments of this application, the functional array is first split using LLM, and then the LLM is divided according to the functional semantics of "achievable / acceptable" by constraint hints. The explicit requirements of the constraint hints include: Those with the same theme will be merged into the same function array (not split for the sake of category); where the same theme refers to the same page, the same field, or the same rule; When the main action or business objective is different, the same topic can be split into different functional arrays; Filter out non-functional content, such as background, overview, and introduction.

[0032] It should be noted that, in the embodiments of this application, in order to allow the splitting results to directly enter the subsequent stages, the output function array adopts a strict JSON array structure, which, for example, includes the following fields: title: Title (≤12 characters); content: 1–2 core descriptions (≤120 words); original: The most relevant original text excerpt (keeping the original wording); category: The main business category, which can be selected precisely from the enumeration (preset optional categories) or defined as "other"; confidence: Confidence level of the main business category, 0.0-1.0; unifiedTags: Sub-tags, which are considered for subsequent knowledge enhancement and correction. They can also be called sub-tag candidates (≤5, must match the union of the tag whitelist, cross-category allowed, but not self-created). Notes: Tips / Notes (not labels).

[0033] For ease of engineering verification, the output function array is denoted as: O={title,content,original,category,confidence,unifiedTags,notes}.

[0034] Define the compliance determination predicate V(O) = True if and only if: "The structure is a JSON array (the specified array structure)" Furthermore, "category belongs to category enumeration" And "unifiedTags" W” And "|unifiedTags|≤5".

[0035] Accordingly, the initial functional unit generation process can be described as U=Validate(LLM(P,D)), where U represents the generated initial functional unit, P is the constraint hint, and D is the PRD; if Validate represents validation, if the validation fails, then trimming or retrying is performed under the same constraints to make the output meet the downstream consumption requirements; if the validation passes, then the functional array output by LLM is the initial functional unit.

[0036] It should be noted that, in the embodiments of this application, the classification expression adopts a combination of "main category + sub-category label" to balance clarity and coverage, wherein: Business main category: The category and confidence (single main category) are given by combining LLM with category enumeration.

[0037] Sub-tags: Determine unifiedTags, then project them to the union of the tag whitelist (unified expression, cross-category, number ≤ 5, and prohibition of self-created tags).

[0038] To ensure consistent expression and executability, unifiedTags are normalized through whitelist projection and prior filtering: First, whitelist projection is performed; then, mutual exclusion / dependency priors are applied for immediate filtering, i.e., consistent filtering of unifiedTags: Conflicting tags (ConflictSet) are removed, and dependency constraints (Dependencies) are satisfied both before and after filtering. Ultimately, |unifiedTags| ≤ 5 and unifiedTags The constraint of W corresponds to the backend whitelist and rule validation implementation. The effect of this classification is to maintain the clarity of the main business category, while supplementing verifiable points across dimensions in a controlled manner, providing more stable input for subsequent check item matching.

[0039] To ensure review and auditing, each initial functional unit retains the original text fragment and source location (sourceSpans / sourceRefs). Each item can include "title, content, original, category, confidence, unifiedTags, notes, source citation". When subsequent stages update categories or tags, a change entry can be added: change={field (changed field), old (previous value), new (new value), reason (reason), evidenceRef (evidence citation)} to record the reasons and basis, thus forming a closed loop of "conclusion-evidence-rule".

[0040] It should be noted that in the embodiments of this application, the category and unifiedTags in the initial functional unit are initial values. Subsequently, in the stage of executing step S102 to perform knowledge enhancement and correction so that each initial functional unit is updated to a target functional unit, the target functional unit also has category and unifiedTags, where the category and unifiedTags are updated values. Of course, other fields in the initial functional unit can also be updated, and correspondingly, the fields in the target functional unit are also updated values.

[0041] S102. For each initial functional unit, knowledge enhancement and correction are performed by performing term similarity retrieval in the terminology database and knowledge similarity retrieval in the knowledge base, so that each initial functional unit is updated to a target functional unit.

[0042] In the embodiments of this application, after obtaining multiple initial functional units, the document review device performs knowledge enhancement and correction for each initial functional unit by performing term similarity retrieval in the terminology database and knowledge similarity retrieval in the knowledge base, so that each initial functional unit is updated to a target functional unit.

[0043] In the embodiments of this application, the terminology database includes a large number of terminology items, which serve as the entry points for concept normalization and semantic retrieval. The terminology items are designed as follows: 1. Purpose: To standardize terminology, reduce ambiguity, and provide "evidence" for classification and labeling.

[0044] 2. What is needed: Canonical name + synonym / alias (e.g., Service Gateway; alias = SGW).

[0045] Evidence-based voting priors: categoryPrior, commonTags, and concise, readable notes are used for category voting and tag completion; optional whitelistAnchor is used for whitelist projection anchoring.

[0046] 3. Design effect: Terminology alignment: unifying synonymous expressions and reducing ambiguity; Evidence voting: Category tips, common tags, and precautions allow you to participate in category voting and tag completion; Semantic recall: Provides a stable nearest neighbor retrieval entry point for text fragments.

[0047] Example: {term:“Service Gateway”, aliases:[“SGW”], categoryPrior:“Resource Operation Class”, commonTags:[“Associate / Unassociate Resources”], notes:[“Cross-region associations must follow the whitelist”]}.

[0048] In the embodiments of this application, the knowledge base includes a large number of knowledge items, which are the smallest knowledge units of business facts and constraints. The knowledge items are designed as follows: 1. Purpose: To make the "facts / constraints" clear, searchable, and convertible into inspection prompts.

[0049] 2. What is needed: The three elements of subject, relation, and object express "who, how, and to whom" (e.g., resource A is only available for… service B).

[0050] Applicable Boundaries: Scope, which includes but is not limited to regions, products, tenants, environments, and conditions, and specifies "under what conditions it is true" (e.g., scope.regions=[region X]; conditions=quota>10).

[0051] Traceability and Evolution: Validity, such as version / effective date / expiration date; Provenance, such as source type / source document / updated date, to facilitate review and updates.

[0052] Prompts / tags: Derived tags and prompt hints can be used directly for prompts or tag completion.

[0053] 3. Design effect: Searchability: Supports hybrid queries combining semantic and structured filtering; Conversion: Relationships and scopes can be automatically converted into prompt labels or inspection tips; Evolvability: Versioning and source recording facilitate incremental maintenance and auditing.

[0054] Example: {Subject: "Resource A", Relation: "Available only in...", Object: "Service B", Scope: {regions: ["Region X"]}, Validity: {version: "v1.0"}, Provenance: {doc: "Internal Specification"}}.

[0055] In the embodiments of this application, the document review device performs knowledge enhancement and correction for each initial functional unit by performing term similarity retrieval in a terminology database and knowledge similarity retrieval in a knowledge base. This includes: retrieving terminology entries in the terminology database that are similar to the vocabulary in the first functional unit to obtain terminology retrieval results; wherein, the first functional unit is any initial functional unit; retrieving knowledge entries in the knowledge base that are similar to the content in the first functional unit to obtain knowledge retrieval results; and, based on the terminology retrieval results and knowledge retrieval results, performing knowledge enhancement and standardization on the subdivision tags of the first functional unit, and correcting the business main category of the first functional unit.

[0056] In the embodiments of this application, the document review device performs knowledge enhancement and standardization on the subdivision tags of the first functional unit based on the terminology retrieval results and knowledge retrieval results, including: deriving a first tag based on the terminology retrieval results and knowledge retrieval results; aggregating the subdivision tags of the first functional unit with the first tag to form a tag candidate set, and performing tag whitelist projection and consistency filtering on the tag candidate set; and updating the subdivision tags of the first functional unit with the tags obtained through tag whitelist projection and consistency filtering.

[0057] In the embodiments of this application, the document review device corrects the business main category of the first functional unit based on the terminology retrieval results and knowledge retrieval results, including: when the confidence level of the business main category of the first functional unit is lower than a threshold, or when the business main category of the first functional unit is other, selecting a business category from preset optional business categories based on the terminology retrieval results and knowledge retrieval results; and updating the business main category of the first functional unit to the business category selected from the preset optional business categories.

[0058] It should be noted that, in the embodiments of this application, for any initial functional unit, such as the first functional unit, knowledge enhancement and correction can be performed according to the above scheme to update the initial functional unit to form the target functional unit. The specific implementation process is as follows: Figure 4 As shown, the following explains the relevant content.

[0059] After semantic decomposition yields the initial functional units, the process uses searchable resources as entry points: the GlossaryService provides term similarity retrieval and metadata (common tags, notes) to form preliminary "tags and hints," while the KnowledgeService returns constraint facts expressed as subject / relation / object and their scope / conditions / effectiveness / source to define applicable boundaries. These two sources of information converge in parallel with the initial functional units onto the same platform, giving classification and tags dual references of contextual evidence and business boundaries.

[0060] It should be noted that, in the embodiments of this application, to avoid drift caused by free identification, the process imposes static constraints on the main business category and sub-categories: the main business category is only taken from preset selectable categories, i.e., a predetermined enumeration, and the sub-categories are only taken from a tag whitelist (which can be maintained by category). When the confidence of the main business category of an initial functional unit is too low or the main business category is "other", a controlled correction is triggered to limit the candidate main business category to the preset selectable categories and maintain "minimum necessary adjustment"; this gating can be written as giving a correction suggestion only when the confidence < τ or when "other" is hit, where the threshold τ is a constant range value agreed upon by the engineering.

[0061] It should be noted that, in the embodiments of this application, during the tag aggregation stage, the sub-tags in the initial functional unit and the tags derived from terms / knowledge (first tags) are first merged into a tag candidate set and then normalized to determine the final sub-tags. Tag whitelist projection is used to ensure consistent expression across documents. The updated representation of the sub-tags unifiedTags is as follows: unifiedTags = Π_W(T), where T is the tag candidate set and W is the whitelist. In addition, the following must also be satisfied: unifiedTags The cardinality constraint between W and |unifiedTags|≤5. In parallel, the scope and conditions in the knowledge facts are transcribed into notes or suggestive tags to supplement the boundary descriptions related to the applicable objects; changes to all fields can be recorded through the evidenceChain, including the changed fields, reasons, and references, forming a traceable closed loop.

[0062] It should be noted that, in the embodiments of this application, after the knowledge enhancement and correction of the initial functional unit are completed, the initial functional unit after knowledge enhancement and correction is the target functional unit. Similar to the initial functional unit, the fields include finalCategory, confidence, unifiedTags, and notes, and may also include evidenceChain. The target functional unit and the downstream rule matching process (ChecksSelectorService) are consistent in terms of fields and value constraints, and can directly enter the check item selection and hierarchical evaluation.

[0063] The following section further explains the engineering details and trade-offs involved in this process.

[0064] First, a unified semantic vector channel is used in the recall phase. The terminology entries in the terminology database and the knowledge entries in the knowledge database are maintained in separate sets within the open-source vector database Milvus. The vector dimension is 1024 (bge-m3), the index is a Hierarchical Navigable Small World (HNSW), and the metric is cosine similarity (COSINE), with typical parameters M=32 and ef≈64. When inputting text into the model, the title and content of the functional unit are used first, with "original" added as a supplement when necessary to ensure recall stability across short texts and long fragments. An upper limit is set for the recall results for each resource type (terms ≤ 5, knowledge ≤ 5), and synonym merging and deduplication are used to ensure a compact candidate set without losing representativeness.

[0065] In evidence aggregation, the metadata of term matching serves two purposes: first, it provides category hints (not mandatory reversals, but only for reference); second, it supplements common tags and precautions highly relevant to the scenario. The facts of knowledge matching, centered on relations and scope / conditions, are mapped as contextual boundary hints or notes. When two sources of information provide contradictory indications regarding the existing main business category or sub-category of the initial functional unit, the gating mechanism prioritizes maintaining the initial functional unit's conclusion. Only when confidence < τ or the initial functional unit's main business category is "other" and external evidence is consistent, does it generate minor correction suggestions. This "minimum necessary correction" ensures the interpretability and controllability of the output, avoiding frequent oscillations under weak evidence.

[0066] The standardization of detailed tags centers on whitelist projection. After mapping the candidate tag set T to the whitelist W via Π_W, consistency filtering is performed: if some tag pairs are mutually exclusive or dependent, the item that is most consistent with the draft semantics and is implied in both terminology and knowledge is retained; if a hierarchical relationship exists (such as "regional restriction" and a specific region tag), the more specific subordinate item is retained. The final updated detailed tags, unifiedTags, follow the cardinality constraint |unifiedTags|≤5, and simultaneously maintains a "category:tag" view for rendering and a "tag ontology" view for rule matching. The former is used for alignment in report presentation, and the latter is used for tag matching.

[0067] The transcription of boundary information follows a fixed mapping: scope.regions / products / tenants / envs and key conditions are compressed into concise cue items for supplementing notes and tags; version and source are entered into the evidenceChain's reference field via the effective version (effective.version) and source document (source.doc) / source link (url) / updatedAt. In this way, any cue arising from the boundary can point back to a searchable knowledge record, forming a traceable link of "text fragment—term / knowledge—output field".

[0068] Regarding record keeping, EvidenceChain uses a structured change log: {field, old, new, reason, references}, where references represent the source of evidence for the change and can include the identifier (id) / specificational name (term) of the term entry and the id / relation / scope summary of the knowledge entry. Changes are only written after passing gating; multiple fine-tunings triggered by multi-source evidence are appended and retained in chronological order. This design allows any correction to be audited or rolled back offline and can be directly referenced in subsequent templated reports.

[0069] Robustness and degradation strategies cover three scenarios. First, when recall fails or there are insufficient available candidates, the process only performs self-consistent pruning within the whitelist and does not introduce external tags. Second, when the number of tags in the tag candidate set exceeds the limit, items that have a more significant impact on the matching weight are retained first, and duplicate items are removed. Third, when there are conflicts or inconsistencies in the scope of knowledge facts, the most recently updated records with higher source credibility are retained first, and the remaining records are marked with uncertainties in the form of notes, rather than being directly rewritten.

[0070] The connection with downstream contracts is reflected in two aspects. First, unifiedTags participate in include / exclude matching as the "tag ontology" on the matching side, while also being presented as "category:tag" for cross-document alignment. Second, confidence participates in the scoring stage as a linear scaling factor to avoid over-amplification caused by low-confidence classification. Based on this, the output of knowledge enhancement and correction possesses both interpretability and traceability, and also satisfies the stable consumption of rule engine and report output.

[0071] For example, in an embodiment of this application, the structure of a target functional unit is as follows: { "functionUnit":{ "id":"fu_12", "title":"Resource A is bound to Service B", "sourceSpans":[[12,34]], "snippet":"...Users can bind resource A to service B...", "category":"Resource operation class", "confidence":0.82, "unifiedTags":["Associate / Unassociate Resources","Region Restrictions"], "evidenceChain":{"changes":[{"field":"category","reason":"Termual Evidence Advantage","evidence":"Hit Term: Service Gateway"}]}, "statusLevel":"Suggests paying attention", "dependencyFailed":false } }

[0072] S103. For each target functional unit, match rule entries in the rule base, review the matched rule entries, and generate review conclusions.

[0073] In the embodiments of this application, after updating each initial functional unit to a target functional unit, the document review device can perform rule entry matching in the rule base for each target functional unit, perform review based on the matched rule entries, and generate review conclusions.

[0074] In the embodiments of this application, the rule base includes a large number of rule entries (ChecklistItems), or simply rule entries, which drive matching / scoring / hierarchy. The rule entries are designed as follows: 1. Purpose: To clarify "when to check what" and to give an actionable priority.

[0075] 2. What is needed: Applicable objects: Applicable business main categories (appliesToCategories) (or all) + required subcategories (includeTags) / excluded subcategories (excludeTags) to determine the trigger boundaries (e.g., Applicable = CAT-EXAMPLE (identifier of business main category); Include = cost item; Exclude = front end only).

[0076] Ranking and stratification: Severity of rule entries + score weights (including but not limited to: base score for category hits / score per tag hit / severity boost) + stratification thresholds (including but not limited to: high score thresholds for rule entries with high severity / low score thresholds for rule entries with low severity); optional calibration (including but not limited to Platt scaling / isotonic regression).

[0077] Conflicts and Priorities: Only the highest score is retained; if prerequisites are not met, the score is automatically downgraded to "deferred"; incompatible pairs are defined.

[0078] 3. Design effect: Explainability: The reasons for a hit, exclusion, or downgrade can all be derived from the fields. Maintainability: Evolves by category and label in the form of rule entries, reducing reliance on model hints; Feasibility: By combining severity and thresholds, a tiered list of "must / recommended / postponed" can be directly generated.

[0079] Example: {id: "fee_policy",appliesToCategories:["CAT-EXAMPLE"],includeTags:["fee item"],severity:"high",scoreWeights:{base:50,tagMatchPerHit:15,severityBoost:15},thresholds:{high:80,low:60}}.

[0080] It should be noted that, in the embodiments of this application, the overall synergistic effect of the aforementioned terminology entries and knowledge entries with the rule entries is as follows: terminology entries are used for "conceptual standardization and evidence voting", knowledge entries are used for "boundary / constraint expression and prompt transformation", and the rule list is used for "matching, scoring and hierarchical". The three form a closed loop of "searchable - interpretable - executable" around the functional unit, supporting consistency and reuse across documents, and providing a foundation for subsequent auditing and version evolution.

[0081] 4. Citation Relationship FunctionUnit.id Inspection results; ChecklistItem.id Check trigger logs; GlossaryItem / KnowledgeItem.id evidenceChain.referencesG refers to the association between terms / knowledge entries and the chain of evidence.

[0082] In the embodiments of this application, the document review device performs rule entry matching in the rule base for each target functional unit, reviews the matched rule entries, and generates review conclusions. This includes: filtering rule entries in the rule base that match the business main category and sub-category tags of the second functional unit, and determining each filtered rule entry as a candidate rule entry; wherein the second functional unit is any target functional unit; determining the review score for each candidate rule entry for the second functional unit; wherein the review score for the second functional unit under a candidate rule entry is determined based on the severity level bonus of the candidate rule entry, the hit rate of the business main category and sub-category tags of the second functional unit, and the confidence level of the business main category of the second functional unit; for the second functional unit, hierarchically classifying the review scores under different candidate rule entries based on the mutual exclusion relationship, prerequisite dependencies, and scoring thresholds of different candidate rule entries, and determining the review opinions under different candidate rule entries; and generating the review conclusion for the second functional unit based on the review opinions of the second functional unit under different candidate rule entries.

[0083] It should be noted that, in the embodiments of this application, any target functional unit, such as the second functional unit, can be reviewed according to the above scheme, and the specific implementation process is as follows: Figure 5 As shown, the following explains the relevant content.

[0084] It should be noted that, in the embodiments of this application, after knowledge enhancement and label normalization are completed, the resulting target functional unit enters the matching and evaluation stage with stable input. This stage revolves around category mapping, label normalization, linear scoring and threshold hierarchical processing, conflict and dependency handling, and ranking output, forming a checklist of directly executable items and maintaining an interpretation consistent with the presentation layer.

[0085] First, matching begins with the standardized entry points for main business categories and tags. The main business category is converted into a rule-recognizable category ID via a name-to-id mapping; if the input is already in a rule-recognizable form, it is used directly. Next, the tag set is normalized to prune the "category: tag" style display values ​​to the "tag body," and tags and tagsForChecklist are merged and deduplicated to form a stable set for rule include / exclude hits. Based on these two standardized inputs, rule entries matching `appliesToCategories` are selected from the rule base as candidate rule entries, and initial filtering is performed using tag inclusion / exclusion conditions.

[0086] After the initial screening is completed, the candidate rule entries are linearly weighted and scored according to the following formula (1): Score=(Base+TagPart+SeverityBoost)ase+TagPart (1) Where Base is the base score for the main business category (default 50); TagPart is the score for the sub-category tag. w_i defaults to 15, and hit_i∈{0,1} indicates whether the sub-label i is hit; SeverityBoost is a severity level boost, derived from the severity level (critical=30, high=15, medium=5, low=0); Confidence is taken from the confidence level of the target functional unit's main business category, and is pinched within the interval [0.5,1.0] to suppress low confidence perturbations. This design balances interpretability and robustness, avoiding the impact of extreme values ​​amplifying noise on the ranking.

[0087] Secondly, handle mutual exclusion and dependency constraints. See also Figure 6Candidate rule entries may exhibit mutual exclusion or prerequisite dependencies: mutual exclusion is managed using group identifiers, retaining only the highest-scoring entry within the same group; prerequisite dependencies are expressed using rule item identifiers, degrading the current candidate rule entry to deferred status when the dependency is not satisfied. Furthermore, conflict detection and resolution can be performed. This process executes a stabilization round after scoring, ensuring the consistency of the output set under explicit constraints without introducing global optimizations beyond the implementation scope. The advantage of this mechanism is that it can obtain a globally consistent solution under "interpretable constraints," naturally corresponding to the layering and priority presentation of the UI layer, avoiding contradictory suggestions caused by local sorting.

[0088] Subsequently, threshold stratification is performed. Stratification is based on the scoring threshold derived from the severity level of each candidate rule entry. For example, rule entries with different severity levels have different derived scoring thresholds. For instance, severity levels can be critical, high, medium, and low, resulting in scoring thresholds of critical=55, high=60, medium=65, and low=70. For a target functional unit, if the review score under a candidate rule entry matches the scoring threshold of that candidate rule entry, it is marked as required; if the threshold is less than 5, it is marked as suggested; candidate rule entries whose dependencies are not met are marked as deferred. These markings serve as part of the review opinion for the target functional unit under that candidate rule entry. This grayscale setting is used to stabilize boundary samples and avoid frequent flipping of the suggestion level due to differential differences.

[0089] Subsequently, the matching and stratification results, along with manually processed feedback and revised document fragments, are recorded on the runtime side for offline analysis of rule trigger rates, threshold adaptability, and the stability of the tag hit structure. Based on this, careful configuration-level adjustments can be made to Base / TagPart / SeverityBoost and the thresholds. This improved mechanism does not alter the online decision-making path, maintaining the interpretability and traceability of matching and stratification.

[0090] Finally, output the review conclusion for each target functional unit. The review conclusion for a target functional unit can be a list of check items (including name, description, severity level, hierarchical status, score, brief description of triggering reason, etc.).

[0091] S104. Based on the review conclusions of different target functional units, generate a review report for the PRD.

[0092] In the embodiments of this application, the document review device can generate a review report of the PRD based on the review conclusions of different target functional units.

[0093] It should be noted that, in the embodiments of this application, when a "to be supplemented / conflict" signal is given for a certain target functional unit, the document review device can generate clarification questions and supplementary suggestions oriented towards the conclusion, and specify the types of evidence that need to be supplemented (such as billing lists, scope of application, boundary conditions). Automatic review is performed after revision until the requirements are met. In the case of long documents and batch processing, progress is continuously fed back at nodes such as semantic decomposition, knowledge enhancement, rule matching, and result summarization; asynchronous orchestration outputs phased results (such as confirmed functional units and preliminary check items) without interrupting the workflow.

[0094] It should be noted that, in the embodiments of this application, the final output review report can be structured around "executable, interpretable, and traceable": the structured results include a summary of finalCategory, unifiedTags, triggering check items and hierarchical status, as well as the source fragments and reasons for changes to the evidence chain, which can be directly converted into an execution list; the human-readable report presents the conclusions and basis in the order of overview, sub-units and appendices, and key information can be backfilled into the PRD appendix or review instructions according to the template, completing the accumulation from problem discovery to revision closure.

[0095] Based on the content of steps S101-S104 above, it can be seen that the technical solution provided by this application mainly involves the following: A dual-enhanced review mechanism combining a terminology base and a knowledge base: terminology entries are used for conceptual standardization and category / label evidence voting, while knowledge entries in the format of "subject-relationship-object + scope / condition / version / source" carry business facts and constraints; the two are combined in the review process for minor corrections and suggestive label completion.

[0096] Controlled representation of hybrid categories and whitelist tags: A hybrid system of "main business category (coarse-grained business scope) + sub-tags (verifiable points across categories)" is adopted; sub-tags can only be selected from a unified whitelist and displayed in groups to ensure consistency and comparability across documents.

[0097] Knowledge-enhanced tiered assessment and rule-based check item matching; matching and scoring "business main category + sub-label" with rule items, and combining severity level-derived scoring thresholds for tiered scoring to form "must / recommended / deferred" review conclusions; prior dependencies and mutually exclusive grouping ensure priority and conflict resolution.

[0098] Semantic decomposition—closed-loop and traceability design for knowledge correction: semantic decomposition generates functional unit drafts → knowledge enhancement and correction → tag unification → rule matching → (if necessary) interactive improvement → closed loop of re-review; the original text fragments, source scope and reasons for change are retained throughout the process to achieve traceability and verifiability of the conclusions.

[0099] Based on the above, the technical solution provided in this application has the following main advantages: Knowledge enhancement review that combines semantics and structure: By integrating "terminal evidence voting + knowledge entries (subject-relation-object + scope / condition)", the review achieves minimal necessary correction and suggestive completion of classification and labels, significantly improving relevance and interpretability compared to schemes that rely solely on rules or pure similarity.

[0100] Consistent representation of hybrid classification and whitelist tags: Complex functions are characterized by a controlled system of "main business category + sub-tags" and the tags are grouped and presented within a unified whitelist. This significantly reduces cross-document ambiguity and noise compared to general function types or free text annotations, and directly improves the stability of check item matching.

[0101] The executability of rule-based matching and hierarchical output: The "business main category + sub-label" is scored with the rule items and the scoring is hierarchically divided. The review conclusion of "must / recommended / postponed" is output. Compared with statistical or generalized suggestions, it is easier to directly convert into an execution list and automate the handling of conflicts / dependencies.

[0102] The engineering implementation capability of loop and traceability: In the closed loop of "semantic decomposition - knowledge correction - rule matching - interactive improvement", the original text fragments, source scope and reasons for change are preserved throughout the process, so that the review conclusions can be verified, reproduced and audited, which is more in line with the process requirements of the engineering team than single analysis or untraceable output.

[0103] This application also provides a document review device. Figure 7 A schematic diagram of the structure of a document review device provided in this application embodiment. Figure 1 .like Figure 7 As shown in the embodiments of this application, the document review device 1 includes: The decomposition module 11 is used to semantically decompose the Product Requirements Document (PRD) into multiple initial functional units. Each initial functional unit contains at least the following types of information: relevant document fragments in the PRD and their source locations, the main business category to which they belong and their confidence level, and detailed labels that identify verifiable constraints across business categories. Update module 12 is used to perform knowledge enhancement and correction for each initial functional unit by performing term similarity retrieval in the terminology database and knowledge similarity retrieval in the knowledge base, so that each initial functional unit is updated to a target functional unit. The review module 13 is used to match rule entries in the rule base for each target functional unit, review the matched rule entries, and generate review conclusions; and generate review reports of the PRD based on the review conclusions of different target functional units.

[0104] In one embodiment of this application, the decomposition module 11 is used to drive a large language model to split the PRD into multiple functional arrays according to functional semantics based on constraint prompts; wherein each functional array includes at least the following types of information: related document fragments in the PRD and their source locations, the business main category to which they belong and their confidence level, and sub-labels that identify verifiable constraints across business categories; performing structural verification and whitelist verification on the multiple functional arrays; wherein the structural verification includes verifying that the functional arrays are of a set array structure, and the whitelist verification includes verifying that the business main category of the functional arrays belongs to a preset optional business category, and that the sub-labels belong to a preset label whitelist; if the verification passes, each of the multiple functional arrays is determined as an initial functional unit, thus obtaining the multiple initial functional units; if the verification fails, based on the constraint prompts, the large language model is driven again to split and verify the PRD into functional arrays according to functional semantics until the multiple initial functional units are obtained.

[0105] In one embodiment of this application, the constraint prompt includes: Those with the same theme will be merged into the same function array; where the same theme refers to the same page, the same field, or the same rule. When the main action or business objective is different, the same topic can be split into different functional arrays; Filter non-functional content.

[0106] In one embodiment of this application, the update module 12 is used to retrieve terminology entries in the terminology database that are similar to the vocabulary in the first functional unit, and obtain terminology retrieval results; wherein, the first functional unit is any initial functional unit; retrieve knowledge entries in the knowledge base that are similar to the content of the first functional unit, and obtain knowledge retrieval results; based on the terminology retrieval results and the knowledge retrieval results, perform knowledge enhancement and standardization on the subdivision tags of the first functional unit, and correct the business main category of the first functional unit.

[0107] In one embodiment of this application, the update module 12 is used to derive a first tag based on the term retrieval result and the knowledge retrieval result; aggregate the subdivision tags of the first functional unit with the first tag to form a tag candidate set, and perform tag whitelist projection and consistency filtering on the tag candidate set; and update the subdivision tags of the first functional unit to the tags obtained after tag whitelist projection and consistency filtering.

[0108] In one embodiment of this application, the updating module 12 is configured to select a business category from preset optional business categories based on the terminology retrieval results and the knowledge retrieval results when the confidence level of the business main category of the first functional unit is lower than a threshold, or when the business main category of the first functional unit is other; and update the business main category of the first functional unit to the business category selected from the preset optional business categories.

[0109] In one embodiment of this application, the review module 13 is used to filter rule entries in the rule base that conform to the business main category and sub-category tags of the second functional unit, and determine each filtered rule entry as a candidate rule entry; wherein, the second functional unit is any target functional unit; for the second functional unit, a review score is determined under each candidate rule entry; wherein, the review score of the second functional unit under a candidate rule entry is determined based on the severity level bonus of the candidate rule entry, the hit rate of the business main category and sub-category tags of the second functional unit, and the confidence level of the business main category of the second functional unit; for the second functional unit, based on the mutual exclusion relationship, prerequisite dependency, and scoring threshold of different candidate rule entries, the review scores under different candidate rule entries are hierarchically divided to determine the review opinions under different candidate rule entries; based on the review opinions of the second functional unit under different candidate rule entries, a review conclusion of the second functional unit is generated.

[0110] Based on the same inventive concept Figure 8 A schematic diagram of the structure of a document review device provided in this application embodiment. Figure 2 .like Figure 8 As shown in the embodiments of this application, the document review device 1 includes: a processor 14, a memory 15, and a communication bus 16; The communication bus 16 is used to realize the communication connection between the processor 14 and the memory 15; The processor 14 is used to execute one or more computer programs stored in the memory 15 to implement the above-described document review method.

[0111] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described document review method.

[0112] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned document review method. The computer-readable storage medium can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or it can be a device including one or any combination of the above-mentioned memories, such as a mobile phone, computer, tablet device, personal digital assistant, etc.

[0113] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0114] This application is described with reference to schematic and / or block diagrams of implementations of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the schematic and / or block diagrams can be implemented by computer program instructions, and combinations of blocks in the schematic and / or block diagrams can be implemented. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the schematic and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0115] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the implementation flow diagram. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0116] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0117] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A document review method, characterized in that, include: Semantic decomposition of the Product Requirements Document (PRD) is performed, dividing it into multiple initial functional units. Each initial functional unit contains at least the following types of information: relevant document fragments in the PRD and their source location, the main business category to which it belongs and its confidence level, and detailed labels that identify verifiable constraints across business categories. For each initial functional unit, knowledge enhancement and correction are performed by performing term similarity searches in the terminology database and knowledge similarity searches in the knowledge base, so that each initial functional unit is updated to a target functional unit. For each target functional unit, rule entries are matched in the rule base, and reviews are conducted based on the matched rule entries to generate review conclusions. Based on the review conclusions of different target functional units, a review report of the PRD is generated.

2. The method according to claim 1, characterized in that, The semantic decomposition of the PRD is divided into multiple initial functional units, including: Based on constraint prompts, the large language model is driven to split the PRD into multiple functional arrays according to functional semantics; wherein each functional array includes at least the following types of information: related document fragments in the PRD and their source location, the business main category to which they belong and their confidence level, and subdivided labels that identify verifiable constraints across business categories; The multiple functional arrays are subjected to structure verification and whitelist verification; wherein, the structure verification includes verifying that the functional array has a set array structure, and the whitelist verification includes verifying that the main business category of the functional array belongs to a preset optional business category and the sub-label belongs to a preset label whitelist. If the verification passes, each of the multiple function arrays is determined as an initial function unit, thus obtaining the multiple initial function units; If the verification fails, based on the constraint prompts, the large language model is re-driven to split and verify the PRD according to functional semantics until the multiple initial functional units are obtained.

3. The method according to claim 2, characterized in that, The constraint prompts include: Those with the same theme will be merged into the same function array; where the same theme refers to the same page, the same field, or the same rule. When the main action or business objective is different, the same topic can be split into different functional arrays; Filter non-functional content.

4. The method according to claim 1, characterized in that, For each initial functional unit, knowledge enhancement and correction are performed through terminology similarity retrieval in the terminology database and knowledge similarity retrieval in the knowledge base, including: The terminology database is used to retrieve terminology entries that are similar to those in the first functional unit to obtain terminology retrieval results; wherein, the first functional unit is any initial functional unit. Retrieve knowledge entries in the knowledge base that are similar to the content in the first functional unit to obtain knowledge retrieval results; Based on the terminology retrieval results and the knowledge retrieval results, the sub-labels of the first functional unit are enhanced and standardized, and the main business category of the first functional unit is corrected.

5. The method according to claim 4, characterized in that, The step of enhancing and standardizing the subdivided tags of the first functional unit based on the terminology retrieval results and the knowledge retrieval results includes: Based on the terminology search results and the knowledge search results, a first tag is derived; The subdivided tags of the first functional unit are aggregated with the first tag to form a tag candidate set, and the tag candidate set is subjected to tag whitelist projection and consistency filtering. The subdivision labels of the first functional unit are updated to labels obtained through label whitelist projection and consistency filtering.

6. The method according to claim 4, characterized in that, The step of correcting the main business category of the first functional unit based on the terminology retrieval results and the knowledge retrieval results includes: If the confidence level of the business main category of the first functional unit is lower than the threshold, or if the business main category of the first functional unit is other, a business category is selected from the preset optional business categories based on the terminology retrieval results and the knowledge retrieval results; The main business category of the first functional unit is updated to a business category selected from the preset optional business categories.

7. The method according to claim 1, characterized in that, For each target functional unit, rule entries are matched in the rule base, and a review is performed based on the matched rule entries to generate a review conclusion, including: In the rule base, rule entries that match the business main category and sub-label of the second functional unit are filtered out respectively, and each filtered rule entry is determined as a candidate rule entry; wherein, the second functional unit is any target functional unit; For the second functional unit, a review score is determined for each candidate rule entry; wherein, the review score of the second functional unit under a candidate rule entry is determined based on the severity level bonus of the candidate rule entry, the hit rate of the business main category and sub-label of the second functional unit, and the confidence level of the business main category of the second functional unit. For the second functional unit, based on the mutual exclusion relationship, prerequisite dependency, and scoring threshold of different candidate rule items, the review scores under different candidate rule items are divided into levels to determine the review opinions under different candidate rule items; Based on the review opinions of the second functional unit under different candidate rule entries, the review conclusion of the second functional unit is generated.

8. A document review device, characterized in that, include: Processor, memory, and communication bus; The communication bus is used to realize the communication connection between the processor and the memory; The processor is configured to execute one or more computer programs stored in the memory to implement the method according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images