Engineering quantity list intelligent matching method

Abstract

The invention discloses an intelligent engineering quantity list matching method, which comprises the following steps of: firstly, performing deep analysis on project description to form a key feature dictionary and form a basis for subsequent accurate matching; then, adopting a two-stage process of coarse screening and fine arrangement: in the coarse screening stage, combining project codes pointing to professional classification with key features capable of quickly locking core elements, performing efficient filtering on a huge standard quota library, and quickly generating a candidate matching list which is controllable in scale and highly related; and in a fine ranking stage, turning to more detailed semantic and feature dual verification, comprehensively utilizing the deep semantic similarity of a complete item description text and an accurate comparison result of a key feature dictionary, and performing fusion calculation to obtain a final score so as to realize accurate ranking of candidate lists. In this way, the semantic gap caused by synonyms, inverted word order, non-standard expression and the like in traditional text matching can be effectively overcome, and the matching accuracy is greatly improved.

Description

Technical Field

[0001] The present invention relates to the field of intelligent matching, and more specifically, to an intelligent matching method for bills of quantities. Background Art

[0002] In the field of construction project cost management, the bill of quantities serves as the core basis for project cost accounting. Accurately matching bills of quantities with corresponding quota sub-items is the foundation of pricing. For a long time, this matching process has relied heavily on the expertise and manual judgment of cost engineers. This is not only time-consuming and inefficient, but also prone to mismatches and omissions due to human oversight or misunderstandings when faced with a massive quota database and non-standardized, diverse list item descriptions. This directly impacts the accuracy and reliability of project costs and becomes a key bottleneck restricting efficient and scientific project management. Therefore, building an intelligent and automated bill of quantities matching solution to improve matching accuracy and efficiency while reducing manual reliance and the risk of errors has become a pressing technical need in the industry.

[0003] To address this need, various intelligent matching methods for bills of quantities have been proposed. Some approaches attempt to directly map and match bill item codes using pre-set rules. However, differences between bill compilation entities or the standard systems they rely on often lead to inconsistent coding systems or complex and variable rules. This makes these methods, which rely on fixed coding rules, less robust and less adaptable to the common situations of missing, incorrect, or system conflicts in real-world projects. Other approaches focus on text similarity calculations, primarily using general algorithms such as cosine similarity to directly compare the textual similarity between bill item descriptions and quota sub-item names or work content. While these methods avoid relying on coding, their core flaw lies in their lack of a deep understanding of the specialized semantics of the engineering field. The widespread use of synonyms, regional idioms, abbreviations, and flexible combinations of feature modifiers (such as strength grade, construction process, and material specifications) in project descriptions makes it difficult for simple literal text similarity calculations to accurately capture the deeper connections between core project features and quota requirements. This semantic gap often leads to matching results that deviate from actual project reality. In addition, faced with a large quota database containing tens of thousands or even hundreds of thousands of quota sub-items, relying solely on a single-level global matching strategy will also result in significant bottlenecks in computational efficiency.

[0004] Therefore, an optimized intelligent matching method for bill of quantities is expected. Summary of the Invention

[0005] In order to solve the above technical problems, the present invention is proposed. An embodiment of the present invention provides an intelligent matching method for bill of quantities, which first forms a key feature dictionary by deeply analyzing the project description, forming the basis for subsequent precise matching; then, a two-stage process of "coarse screening-fine sorting" is adopted: in the coarse screening stage, the project code pointing to the professional classification is combined with the key features that can quickly lock the core elements, and the huge standard quota library is efficiently filtered to quickly generate a candidate matching list with controllable scale and high relevance; in the fine sorting stage, it turns to a more detailed double verification of semantics and features, comprehensively utilizing the deep semantic similarity of the complete project description text and the accurate comparison results of the key feature dictionary, and obtains the final score through fusion calculation to achieve accurate sorting of the candidate list. In this way, it can effectively overcome the semantic gap caused by synonyms, word order reversal, non-standard expressions, etc. in traditional text matching, and greatly improve the accuracy of matching.

[0006] According to one aspect of the present invention, a method for intelligent matching of bills of quantities is provided, comprising: Structuring the original engineering bill of quantities file obtained to obtain a structured bill of quantities data table; Extracting a first list item from a structured list data table, the first list item including an item code string and an item description text; performing key feature extraction on the item description text in the first list item to obtain a first list item feature dictionary; Based on the item code character string in the first list item and the first list item feature dictionary, the standard quota library is roughly screened for a candidate set to obtain a roughly screened candidate matching list; Based on the item description text in the first list item and the first list item feature dictionary, calculating a final fusion score between the first list item and each to-be-matched item in the coarse-screened candidate matching list to obtain a final matching ranked list; Extract and display the top-3 matching items with the final fusion score from the final matching sorted list.

[0007] Compared with the existing technology, the present invention provides a method for intelligent matching of bills of quantities. First, it deeply analyzes the project description to form a dictionary of key features, which forms the basis for subsequent precise matching. Then, it adopts a two-stage process of "coarse screening-fine sorting": in the coarse screening stage, the project code pointing to the professional classification is combined with the key features that can quickly lock the core elements, and the huge standard quota library is efficiently filtered to quickly generate a candidate matching list with controllable scale and high relevance. In the fine sorting stage, it turns to a more detailed double verification of semantics and features, comprehensively utilizing the deep semantic similarity of the complete project description text and the accurate comparison results of the key feature dictionary, and obtains the final score through fusion calculation to achieve accurate sorting of the candidate list. In this way, it can effectively overcome the semantic gap caused by synonyms, word order reversal, non-standard expressions, etc. in traditional text matching, and greatly improve the matching accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The above and other objects, features, and advantages of the present invention will become more apparent through a more detailed description of the embodiments of the present invention in conjunction with the accompanying drawings. The accompanying drawings are provided to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and are not intended to limit the present invention. In the drawings, the same reference numerals generally represent the same components or steps.

[0009] Figure 1 Flowchart of a method for intelligent matching of bill of quantities according to an embodiment of the present invention; Figure 2 Schematic diagram of data flow of the intelligent matching method of bill of quantities according to an embodiment of the present invention. DETAILED DESCRIPTION

[0010] Below, the exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments of the present invention, and it should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0011] As used herein and in the claims, unless the context clearly indicates otherwise, the terms "a," "an," "an," and / or "the" are not intended to refer to the singular but may include the plural. Generally speaking, the terms "comprises" and "include" only indicate the inclusion of the steps and elements specifically identified, and these steps and elements do not constitute an exclusive list. A method or apparatus may also include other steps or elements.

[0012] Although the present invention has made various references to certain modules in the system according to an embodiment of the present invention, however, any number of different modules can be used and run on the user terminal and / or server. The modules are only illustrative, and different aspects of the system and method can use different modules.

[0013] Flowcharts are used in this disclosure to illustrate the operations performed by systems according to embodiments of the present invention. It should be understood that the preceding or following operations do not necessarily need to be performed in exact order. Instead, various steps may be processed in reverse order or simultaneously, as needed. Furthermore, other operations may be added to these processes, or one or more operations may be removed from these processes.

[0014] Below, the exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments of the present invention, and it should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0015] In the technical solution of the present invention, a method for intelligent matching of bill of quantities is proposed. Figure 1 Flowchart of a method for intelligent matching of bill of quantities according to an embodiment of the present invention. Figure 2 This is a data flow diagram of the intelligent matching method for bill of quantities according to an embodiment of the present invention. Figure 1 and Figure 2 As shown, the intelligent matching method of the bill of quantities according to an embodiment of the present invention includes the following steps: S1, structuring the obtained original bill of quantities file to obtain a structured bill data table; S2, extracting the first bill item from the structured bill data table, wherein the first bill item includes a project code string and a project description text; S3, extracting key features of the project description text in the first bill item to obtain a first bill item feature dictionary; S4, based on the project code string in the first bill item and the first bill item feature dictionary, coarse screening of the candidate set of the standard quota library to obtain a coarse screening candidate matching list; S5, based on the project description text in the first bill item and the first bill item feature dictionary, calculating the final fusion score between the first bill item and each to-be-matched item in the coarse screening candidate matching list to obtain a final matching ranked list; S6, extracting and displaying the to-be-matched items whose final fusion score is Top-3 from the final matching ranked list.

[0016] In particular, the S1 performs structured processing on the original engineering bill of quantities file obtained to obtain a structured bill of quantities data table. The original engineering bill of quantities file refers to an engineering project pricing file provided by the user and with an unfixed format, such as an Excel spreadsheet, a PDF document, or a file exported by a specific cost estimation software. The structured bill of quantities data table refers to a two-dimensional data set obtained after processing, with a unified and regular table structure, in which each row represents an independent bill of quantities item and each column represents a specific attribute of the bill of quantities item (such as project code, project name, etc.), and is the direct data source for all subsequent calculations. In the technical solution of the present invention, by performing structured processing on the original engineering bill of quantities file obtained, the uncertainty and heterogeneity of the original data can be eliminated, and a stable, reliable, and uniformly formatted data foundation can be established for subsequent automated analysis.

[0017] Specifically, in a specific example of the present invention, the obtained original bill of quantities file can be structured through the following steps: First, the file type of the original bill of quantities file is identified to obtain a file type identification result. It should be understood that in engineering practice, the formats of the original bill of quantities files uploaded by users may be varied, such as common Excel spreadsheets, non-editable PDF documents, or proprietary format files exported by specific cost software. Each file format has its own unique data storage structure and reading method. Only by accurately identifying the file type can the system call the matching and adapted parser to correctly read and extract data, thereby ensuring the universality and robustness of the entire method for files from different sources, and avoiding parsing failures or data confusion due to format mismatch.

[0018] The file type identification result is a clear identifier (for example, a string "Excel" or "PDF"), which is used to refer to the specific format of the original file.

[0019] In practice, the system first performs a preliminary analysis based on file extensions. Upon receiving a raw bill of quantities file, the system parses the file extension from the file name string. The system maintains a mapping table of known extensions and file types, for example, {".xls": "Excel", ".xlsx": "Excel", ".pdf": "PDF"}. The system compares the parsed extension against this mapping table to generate a preliminary recognition result.

[0020] However, since file extensions can be easily modified by users, relying solely on this method is risky. Therefore, to further ensure the accuracy of identification, the system further performs a deep verification based on the binary information in the file header. Specifically, the system opens the file in binary mode and reads several bytes at the beginning of the file. This binary sequence is then compared with a preset "magic number" library. This library stores unique binary signatures for various common file formats. For example, all files in the ".xlsx" format are essentially a ZIP compressed package, so their file header binary information will conform to the ZIP format specifications. Through this byte-level comparison, the system can obtain a highly reliable file type judgment. Ultimately, the system will combine the results of the above two methods, usually taking the result of the deep verification as the basis, to generate a final, deterministic file type identification result.

[0021] Next, an adaptive parser is selected based on the file type identification result, and the original engineering quantity list file is parsed based on the adaptive parser to obtain the original data after preliminary parsing. It should be understood that different file types have completely different internal data encoding and organizational structures. For example, Excel files store data in the form of cells of worksheets, rows, and columns, while PDF files describe page layout and text in the form of object streams. Any mismatch will result in the inability to read data or the extraction of meaningless garbled codes. In the technical solution of the present invention, the original engineering quantity list file is parsed based on the adaptive parser to ensure that the system can access its content in a correct manner, thereby providing the information encapsulated inside the file to subsequent processing programs, laying the original data foundation for the final structuring.

[0022] An adapted parser is a specialized software module or library function designed to understand and process the binary structure or text encoding of a specific file format. The raw data after initial parsing is a data structure stored in computer memory, typically represented as a two-dimensional array, list of lists, or data frame. It reflects all visible information in the file, including but not limited to valid data rows, table headers, blank rows, comments, and even formatted merged cell information.

[0023] In specific implementation, first, the system uses the file type recognition result as the input key and maps it to a specific parser object or function pre-integrated in the system; when the received file type is "Excel", it automatically selects and instantiates an Excel file reader based on the Python pandas library; when the type is "PDF", it selects a PDF text extractor based on the PyPDF2 library. This mechanism ensures the automation and accuracy of the operation.

[0024] Next, the adapted parser is called to perform file parsing. Once the adapted parser is selected, the system will call the core function of the parser and pass the path or data stream of the original bill of materials file as a parameter to the adapted parser. The adapted parser will open the file and read and decode the file content byte by byte or object by object according to the specifications of its corresponding format. For table files, the parser will identify worksheets, rows, and columns, and extract the data in each cell to load the entire file or the contents of the specified worksheet into the memory completely and losslessly, and obtain the original data after preliminary parsing. This data retains the original row and column layout, providing complete context information for the next step of header positioning and data cleaning.

[0025] Next, the raw data after preliminary parsing is subjected to table header location and column mapping to obtain a dictionary of data row and column mapping relationships. Because the header position of a project checklist file is not fixed, the column order can vary, and column naming also varies based on the compiler's habits (for example, "project code" might be named "checklist code" or "code"). The technical solution of the present invention automatically discovers the key information defining the data structure—the table header—through an intelligent algorithm, and establishes a correspondence between the original column names and the system's internal standard fields, thereby resolving the heterogeneity of data sources and enabling subsequent data screening and extraction to be performed accurately and automatically.

[0026] The table header specifically refers to one or more rows in the original data that define the meaning of each column. Data row data refers to the set of valid data rows in the original data containing the actual list item content, excluding the table header and other non-data rows (such as blank rows and title rows), after locating the table header. The column mapping dictionary is a key data structure that establishes the correspondence between column headers in the original file and the system's internal standard field names, resolving data extraction challenges caused by varying column names across different files.

[0027] In practice, the system first traverses the first N rows of the initially parsed raw data (N is a configurable, reasonable exploration depth, such as 20 rows). For each row, a header similarity score is calculated. This score can be calculated using a weighted sum function. The core idea is to check how many predefined keywords with high recognition in the field of project checklists are included in the row. This keyword library is pre-set and includes multiple variations of terms such as "project code," "checklist code," "project name," "project characteristics," "project description," "unit of measurement," and "project quantity."

[0028] Once the header row is identified, the system iterates through each cell in that row (i.e., the original column headings). For each column heading, the system matches it against an internally maintained library of standard field synonyms. This library associates a set of possible aliases (e.g., "Project Code," "Invoice Number," "Code," etc.) with each standard field (e.g., "Listing Code Column"). Whenever a match is found between an original column heading and a synonym for a standard field, the system creates a new mapping record in the column mapping dictionary. This dictionary is highly flexible and can handle complex situations where a standard field is composed of multiple original columns. For example, the standard field "Listing Description Column" might be composed of both the "Project Name" and "Project Characteristics" columns from the original file. In this case, the corresponding dictionary value would be a list of multiple original column names. This dictionary, along with the identified data row, is passed to the next processing step, providing precise data extraction instructions.

[0029] Subsequently, based on the column mapping relationship dictionary, after the data rows are screened and fine-grained, structured data objects are generated to obtain a structured inventory data table. It should be understood that after the table header has been successfully located and the column mapping relationship has been established, although the system knows the structure of the data, it is still mixed with a lot of noise and format inconsistencies. Therefore, in the technical solution of the present invention, through a systematic screening, cleaning and generation process, all interference information that is useless or even harmful to subsequent analysis is removed, and the effective information is unified into a standardized data paradigm, thereby ensuring that the final output structured inventory data table has a high degree of consistency, accuracy and availability, providing a high-quality data foundation for subsequent core algorithms such as feature extraction and similarity calculation.

[0030] Among them, data row filtering aims to remove rows that do not contain valid list item information from the data row data, such as completely blank rows, summary statistical rows containing words such as "total" and "subtotal", and other formatted decorative or comment rows. Fine-grained cleaning is a deep processing that standardizes the content of a single data cell. Its operation object is each relevant cell of the valid data row left after filtering. The processing content includes but is not limited to removing redundant blank characters, converting character encoding (such as full-width to half-width), and processing special control characters. Structured data object generation refers to creating a new data record (or object) that conforms to the unified data model within the system based on the column mapping relationship dictionary for each valid data row that has been filtered and cleaned. The structured list data table is a collection of all these generated structured data objects. It is a regular two-dimensional data table that can be directly called by subsequent programs.

[0031] In practice, the system first filters rows based on rules. During this process, an iterator is started with the column mapping dictionary and the row data as input, traversing all rows one by one. During the traversal process, each row is tested against one or more predefined rules. These rules include: Empty row detection, that is, determining whether all cells in a row are empty or contain only blank characters. If so, the row is discarded directly; To identify summary rows, the system scans the contents of a specific column (usually the project name column) and applies regular expressions or keyword matching (for example, searching for substrings such as "total," "subtotal," and "grand total") to identify summary rows. Once a match is found, the row is deemed invalid and is filtered out. Structural integrity checks. For example, the system can stipulate that a valid list item row must have a non-null value in the "Item Code" column. Rows that do not meet this condition will be considered invalid and filtered out. Only rows that pass all rule checks will be passed to the next processing step.

[0032] Next, for each valid data row that passes the filter, the system will further perform deep cleaning of the cell data within it. For the content of each target cell, the system will execute a series of standardization operation functions. These functions include: Whitespace characters are regularized, that is, string processing functions (such as strip()) are called to remove all whitespace before and after the content, and regular expressions are used to replace multiple consecutive whitespace characters (including spaces, tabs, etc.) in the middle of the content with a single space; Character set normalization, that is, converting any full-width characters (such as "C35") in the text into half-width characters ("C35") to ensure consistency in subsequent processing; Special character processing, such as removing or replacing line breaks and carriage returns in text, ensures that each cell content is a clean single-line string.

[0033] Next, for each filtered and cleaned data row, a new, standardized data object (such as a Python dictionary or a Java POJO object) is created. This object is generated entirely according to the column mapping dictionary. The system iterates over each key in the dictionary (i.e., the system's standard field name). For each key, the system extracts the corresponding cleaned data from the currently processed data row based on its corresponding value (i.e., the original column name or a list of column names). If the value is a single column name, the data for that column is directly extracted; if the value is a list of column names, the system merges the data from these columns according to preset rules (usually string concatenation separated by spaces or specific delimiters) to form a composite field. Finally, after all standard fields are populated, they are added to a collection. Once all valid data rows have been processed, a structured inventory data table is obtained.

[0034] Specifically, S2 extracts the first list item from the structured list data table. This first list item includes a project code string and a project description text. It should be understood that during the bill of quantities matching process, the original list file undergoes structured processing to generate a list data table, which contains multiple list items. By extracting the first list item, the system can focus on a single item to be matched, avoiding the inefficiencies and error accumulation associated with global processing.

[0035] The project code string is a hierarchical code structured according to national or industry standards that uniquely identifies the category and attributes of a checklist item. The project description text, a natural language description of the project's specific construction content, materials, specifications, and other information, serves as the foundation for semantic understanding and feature analysis.

[0036] During implementation, the system first locates and accesses a structured inventory data table in memory or temporary storage. This data table is a regular data structure, such as a DataFrame or a list of objects, where each row represents a separate inventory item. Next, the system traverses the data table or, based on preset instructions (for example, starting processing from the first row), selects a specific inventory item as the current processing target, namely the first inventory item. In practice, the system typically performs this operation in a loop or iterative manner, extracting each inventory item in the table one by one and performing the complete matching process on each item until all items have been processed. Specifically, the system reads the field value corresponding to the item code to obtain the item code string, and simultaneously reads the field value corresponding to the item description (this field may be a combination of multiple fields such as "Item Name" and "Item Features" in the original file) to obtain the item description text. The item code string and item description text together constitute the complete information of the first inventory item and are passed as data objects to subsequent processing modules. Specifically, S3 extracts key features from the project description text in the first list item to obtain a first list item feature dictionary. It should be understood that while the project description text in the bill of quantities contains all the key information required for matching, its natural language form is ambiguous and ambiguous to computers. For example, "cast-in-place C35 concrete rectangular beam" and "rectangular beam, concrete strength C35, cast-in-place process" appear identical to humans, but differ to simple string comparison algorithms. Without feature extraction, subsequent matching can only rely on superficial text similarity calculations, failing to capture the precise requirements of core elements in the engineering field, such as components, materials, processes, and specifications. This can lead to problems such as low matching accuracy and mismatches and omissions. Therefore, in the technical solution of the present invention, by extracting key features from the project description text in the first list item, key engineering semantics such as "component type," "strength grade," and "construction process" implicit in the text are made explicit and atomized, and organized into a standardized first list item feature dictionary, providing a solid, reliable, and interpretable basis for subsequent candidate set screening and accurate scoring.

[0037] Specifically, in a specific example of the present invention, the key features of the project description text in the first list item can be extracted by the following steps: First, the project description text is matched with a regular expression based on a regular expression engine to obtain a regular result and a text for NER. It should be understood that the project description text usually contains structured features (such as strength grade, size specifications) and unstructured semantic information (such as process, component type). Features such as strength grade (such as "C35") and thickness (such as "20mm") have fixed patterns (letter + number combination), but are easily ignored or misinterpreted by general NER models. In the technical solution of the present invention, the regular expression engine accurately captures such patterned features through preset rules to avoid interference from semantic parsing. At the same time, separating the matched structured features can significantly improve the recognition accuracy of the subsequent NER model for the remaining text.

[0038] Among them, a regular expression is a special text string used to describe a string pattern and can express complex matching rules in a very concise way.

[0039] In implementation, the system first launches a regular expression engine, which loads a predefined rule library containing a series of regular expressions written by domain experts for common formatting parameters in the construction industry. For example, the rule library might include patterns for matching strength grades, rebar specifications, and dimensions. The engine then iterates over each regular expression in the rule library and applies it to the project description text. This matching process is global, searching for all substrings that match the pattern across the entire text. When a regular expression successfully matches one or more substrings in the text, these matched substrings (for example, "C35") are collected into a set, the regular expression result. The system then performs a text reduction operation to generate a second output. Specifically, the system removes from the original project description text all substrings that have been successfully matched and extracted into the regular expression result. The text remaining after this removal operation is the text used for NER.

[0040] Next, the text to be used for NER is input into the NER model to obtain NER results. It should be understood that in the previous step, although parameters with fixed patterns such as "C35" are accurately extracted, a large amount of key engineering information, such as component type ("rectangular beam"), construction process ("cast-in-place"), and material ("reinforced concrete"), is expressed flexibly and diversely, without fixed, predictable string patterns. For example, "cast-in-place reinforced concrete beam" and "beam, reinforced concrete, cast-in-place construction" are semantically equivalent, but their text structures are completely different. Relying solely on simple text matching would fail to identify this equivalence. Therefore, in the technical solution of the present invention, the text to be used for NER is input into the NER model to convert the unformatted natural language text into structured information composed of standardized engineering concepts (entities) and their categories, thereby greatly improving the depth and breadth of feature extraction and laying a solid semantic foundation for subsequent high-precision intelligent matching.

[0041] Among them, the NER result is a structured data set, usually a list, and each element in the list is a combination of a recognized entity string and its corresponding category label.

[0042] In specific implementation, first, the system loads and initializes a pre-trained named entity recognition (NER) model for the construction engineering field. This model is loaded into memory when the program starts. It contains the definition of the model's own network structure and the weight parameters obtained through training with a large amount of domain data. These weight parameters solidify the model's ability to understand text in the engineering field. Next, the text used for NER is preprocessed, which mainly includes word or character segmentation of the text. For Chinese text, a character segmentation strategy is generally adopted, that is, the input text string (such as "cast-in-place reinforced concrete rectangular beam") is segmented into a character sequence (['现', '浇', '钢', '筋', '混', '凝', '土', '矩','形', '梁']). Then, this character sequence is converted into a corresponding sequence of digital ID. Subsequently, the preprocessed digital ID sequence is formally used as input and fed into the NER model for inference calculation. The model (such as a neural network based on structures like BERT or BiLSTM-CRF) processes each digital ID in the sequence one by one and predicts a label for each ID (i.e., each character) in combination with its context information. These labels usually follow annotation systems such as BIO or BIOES. For example, B-component represents the start of an entity of the "component" type, I-component represents the middle part of an entity of the "component" type, and O represents non-entity. Finally, the system post-processes or decodes the label sequence output by the model. According to the label sequence (such as ['B-process', 'E-process', 'B-material', 'I-material', 'I-material', 'I-material', 'E-material', 'B-component', 'I-component', 'E-component']), the characters corresponding to consecutive labels belonging to the same entity are recombined and the category of the entity is attached. For example, the system combines the characters '矩','形', '梁' marked as B-component, I-component, and E-component into the entity "rectangular beam" and assigns it the category of "component". All the entities and their categories identified in this way together form a set, that is, the NER result.

[0043] Subsequently, the regularization results and NER results are merged to produce the first list item feature dictionary. It should be understood that the regularization results extract structured, patterned engineering attributes (e.g., strength grade "C35" and thickness "20mm"), whose values ​​are accurately matched according to preset rules, but fail to understand semantic context. The NER results identify engineering entities within unstructured text (e.g., process "cast-in-situ" and material "reinforced concrete"), relying on semantic models to understand specialized terminology but lacking sensitivity to digitally encoded features. Therefore, to enable subsequent modules such as candidate set screening and final score calculation to uniformly and comprehensively utilize all extracted key features within a unified framework, the technical solution of the present invention merges the regularization results and NER results to aggregate feature information from all dimensions into a single, standardized structure, resulting in the first list item feature dictionary. This simplifies subsequent processing logic, reduces the coupling between system modules, and provides a complete and consistent data foundation for accurate and efficient feature-level matching.

[0044] The first list item feature dictionary is a structured data object that fully describes all key engineering features contained in the original project description text in the form of key-value pairs. The keys are standardized feature categories, such as "strength level" and "process," and the values ​​are corresponding specific content extracted from the text.

[0045] In practice, the system first initializes an empty data structure. In programming practice, this data structure is typically a dictionary, hash map, or similar associative array that supports key-value storage. This empty data structure serves as the carrier for the first list item's feature dictionary. Next, the system iterates through the regularization results, adding each key-value pair (such as the key 'strength level' and the value 'C35') to the newly created empty dictionary. Next, the system iterates through each element (i.e., each entity-category pair) in the NER results, similarly adding the category (such as 'process') as the key and the entity content (such as 'cast-in-place') as the value to the dictionary being constructed. By sequentially processing and adding all the information from the regularization results and NER results, the original empty dictionary is gradually filled, resulting in the first list item's feature dictionary.

[0046] In particular, the S4, based on the project code string in the first list item and the first list item feature dictionary, performs a rough screening of the candidate set of the standard quota library to obtain a rough screening candidate matching list. Specifically, in a specific example of the present invention, first, based on the project code string, the standard quota library is subjected to a coding-based hierarchical filtering to obtain a first rough screening candidate matching set. It should be understood that the project code of the bill of quantities is a product of national or industry standardization, and each bit or each segment thereof represents a specific engineering category, sub-item or sub-item. Therefore, by matching the prefix of the code, the search space can be directly limited to the quota items belonging to the same category as the item to be matched, for example, directly separating "earthwork" from "concrete engineering". This high-level filtering based on structured information is not only extremely efficient in calculation, but also can fundamentally exclude a large number of completely irrelevant quota items, which is the basis for ensuring the accuracy of subsequent screening.

[0047] In specific implementation, the following steps can be used to perform a rough screening of the candidate set in the standard quota database: First, extract the code prefix of the project code string. That is, based on the preset rules or length, the system extracts the important prefix part representing the classification level from this complete code string, usually the first N characters of the string; then, using the code prefix as the query index, the first rough screening candidate matching set is returned from the standard quota database. Here, at the database level, in order to achieve efficient query, the code field of the standard quota database is usually indexed. After executing this query, the database will return a set of all quota items that meet the classification conditions of this level, namely the first rough screening candidate matching set.

[0048] The code prefix represents the project's high-level category within the entire engineering classification system. For example, in a 12-digit code, the first two, four, and six digits may represent the engineering category, sub-project, and sub-item, respectively.

[0049] Taking the solution of the present invention as an example, first, the coding prefix of the project coding string "010401001001" is extracted, such as the first 6 digits "01040", which represents "civil engineering-concrete and reinforced concrete engineering-cast-in-place concrete beams"; then, using this coding prefix "01040" as an index, a query is performed in the standard quota library, and all quota items with codes using this prefix are returned to form a first coarse screening candidate matching set.

[0050] Next, based on the first list item feature dictionary, the standard quota library is subjected to reverse index filtering of core feature keywords to obtain a second coarse screening candidate matching set. It should be understood that the first list item feature dictionary may contain multiple features, such as components, materials, processes, specifications, etc., but not all features have the same degree of distinction and importance. For example, in the matching of a concrete project, the "component" type (such as "rectangular beam") and "process" (such as "cast-in-place") are usually more core defining than general material descriptions (such as "reinforced concrete"). Actively selecting these most representative core feature keywords through preset rules can make the subsequent retrieval process more focused and efficient, avoiding the introduction of a large number of irrelevant candidate entries due to matching some minor or general features, thereby ensuring the accuracy of content filtering from the source.

[0051] In specific implementation, reverse index filtering of core feature keywords in the standard quota database can be performed through the following steps: First, the first and second core keywords are extracted from the first list item feature dictionary. During this process, the system first receives the first list item feature dictionary as input, which is a set of key-value pairs. The system internally configures a feature priority list or a set of selection rules that define the importance of different feature types (i.e., the "keys" in the dictionary). For example, the rule might specify that "component" has the highest priority, while "process" has the second highest priority. During execution, the system searches the input feature dictionary for corresponding keys according to this priority order. It first checks whether the key "component" exists. If so, its corresponding value is used as the first core keyword. Next, it searches for the key "process" and, if so, its corresponding value is used as the second core keyword. Then, using the first and second core keywords as query indices, the system returns the third and fourth coarse-screened candidate matching subsets from the standard quota database. Here, the query index data structure resembles a giant dictionary. Its "keys" are all possible keywords that may appear in the quota database description (such as "rectangular beam" and "cast-in-place"), and its "values" are a list containing the unique identifiers (IDs) of all quota items containing this keyword. When the system receives the first core keyword extracted in the previous step, it directly uses this keyword as the query key to search the inverted index and instantly obtains the corresponding ID list, which is the third coarse-screened candidate matching subset. Similarly, the system then searches with the second core keyword, obtaining another ID list, the fourth coarse-screened candidate matching subset. The inverted index is a core data structure that stores the mapping from a word to a list of documents containing that word. Subsequently, the intersection of the third coarse-screened candidate matching subset and the fourth coarse-screened candidate matching subset is taken to obtain the second coarse-screened candidate matching set. In the technical solution of the present invention, by calculating this intersection, the system can accurately identify candidates that align with the item to be matched across multiple core semantic dimensions, thereby greatly improving the accuracy of content filtering and providing a high-quality candidate pool for the final matching results. During this process, the system receives the two quota item ID lists generated in the previous step (i.e., the third and fourth coarse-screened candidate matching subsets) as input. Then, the system calls a set intersection function, which efficiently finds the IDs that exist in both lists and puts these common IDs into a new list or set to obtain the second coarse-screened candidate matching set.

[0052] Furthermore, an intersection operation is performed on the first and second coarse-screened candidate matching sets to obtain a coarse-screened candidate matching list. It should be understood that the first coarse-screened candidate matching set ensures that the candidate items are correct at the engineering classification level (e.g., "cast-in-place concrete beam engineering"), while the second coarse-screened candidate matching set ensures that the candidate items are relevant in terms of core semantic content (e.g., containing the "rectangular beam" and "cast-in-place" features). However, each of these sets may have limitations. For example, the first set may contain items in the same classification but with inconsistent content (e.g., "cast-in-place L-shaped beam"), while the second set may contain items with similar content but incorrect classification. Using either set alone cannot guarantee the highest matching quality. Therefore, in the technical solution of the present invention, an intersection operation is performed on the first and second coarse-screened candidate matching sets to accurately identify quota items that are both correctly classified and relevant in terms of core content. This eliminates any interference items that only meet a single condition, significantly reducing the burden on the subsequent final matching process and fundamentally improving the accuracy and efficiency of the entire matching process.

[0053] In particular, the S5, based on the project description text in the first list item and the feature dictionary of the first list item, calculates the final fusion score between the first list item and each item to be matched in the coarse screening candidate matching list to obtain a final matching sorted list. Specifically, in a specific example of the present invention, first, based on the project description text of the first list item, the semantic similarity score between the first list item and each item to be matched is calculated. It should be understood that the project description text is a natural language, and its expression is flexible and changeable. For example, "cast-in-situ concrete beam" and "concrete beam, cast on site" are very different in literal sense, but highly consistent in semantics. Traditional keyword matching or simple text comparison cannot effectively handle this situation of synonymous but different forms. Therefore, in the technical solution of the present invention, the semantic similarity score between the first list item and each item to be matched is calculated to measure the closeness in meaning between the two texts. The higher the score, the closer the meaning of the two is.

[0054] In specific implementation, text embedding encoding is first performed on the project description text of the first list item to obtain the first list item's text embedding encoding vector. It should be understood that the description text of a construction project (e.g., "cast-in-place reinforced concrete C35 rectangular beam") contains a large amount of specialized terminology, complex structures, and implicit semantic relationships, making it difficult for traditional text processing methods to accurately quantify its deep semantics. Therefore, in the technical solution of the present invention, text embedding encoding is performed on the project description text of the first list item. This allows the system to learn the deep meaning of words and sentences in a specific context and map it to a specific coordinate point in a high-dimensional vector space.

[0055] In a specific implementation, the item description text of the first list item can be input into a text semantic encoder based on the Bert model to obtain an embedded coding vector of the item description text of the first list item.

[0056] Subsequently, the cosine similarity between the text embedding encoding vector of the project description of the first list item and the semantic vector of each item to be matched is calculated as the semantic similarity score. It should be understood that the project description text (such as "cast-in-place reinforced concrete C35 rectangular beam") contains a large number of professional terms, synonymous expressions and implicit process characteristics, and relying solely on keyword matching or feature dictionary comparison cannot capture the overall semantic association of the text. The cosine similarity calculation can convert such semantic relationships into quantifiable geometric relationships through directional comparison in the vector space. Therefore, in the technical solution of the present invention, the cosine similarity between the text embedding encoding vector of the project description of the first list item and the semantic vector of each item to be matched is calculated to break through the limitations of the surface character string, evaluate the similarity between the list item and the quota item from a semantic level, and provide a semantic dimension independent of feature matching for the subsequent fusion score.

[0057] Next, based on the first-item feature dictionary for the first list item, a feature matching score is calculated between the first list item and each of the items to be matched. It should be understood that while semantic similarity can capture the overall meaning, it lacks sensitivity to key parameters that can significantly differ in engineering (e.g., concrete strength "C35" vs. "C40"). Therefore, in the technical solution of the present invention, a feature matching score is calculated between the first list item and each of the items to be matched to verify each extracted key feature (e.g., component, process, strength grade, etc.). This approach mitigates the ambiguity of semantic matching, ensuring that the final matching results are rigorous and accurate across all key engineering parameters, providing a "rigid" guarantee and a high degree of interpretability for the matching results.

[0058] In a specific implementation, first, key features are extracted for each item to be matched to obtain a matching item feature dictionary. In a specific example of the present invention, key features can be extracted for each item to be matched by the following steps: first, regular expression matching is performed on each item to be matched based on a regular expression engine to obtain a second regular result and a second text for NER; the second text for NER is input into a second NER model to obtain a second NER result; and the second regular result and the second NER result are merged to obtain a matching item feature dictionary.

[0059] The first list item feature dictionary and the matching item feature dictionary are then input into a feature matching scoring function to generate a feature matching score. This function solidifies the complex, multi-dimensional feature comparison logic into a formal, repeatable algorithm. It not only determines whether features match, but also provides a precise, standardized score based on the degree of match and the inherent importance of each feature, providing a robust, reliable, and highly interpretable input for the final fusion score calculation.

[0060] The feature matching scoring function is a core software algorithm module that codifies the business logic for comparing two feature dictionaries. This function is configurable; for example, the weights of different features can be adjusted to suit different engineering domains or matching requirements. The feature matching score is a standardized value (usually between 0 and 1). This score is not a subjective judgment, but rather a quantitative measure of the identity between two items at the structural feature level, calculated through a rigorous algorithm. A higher score indicates a closer match between the two items on key engineering parameters.

[0061] In specific implementation, the first list item feature dictionary and the matching item feature dictionary are first input into the feature matching scoring function, which then performs calculations based on a pre-defined scoring strategy. A typical and efficient implementation utilizes a weighted matching algorithm. First, the system loads a pre-set feature weight mapping table, which assigns a numerical weight to each possible feature type (such as "component," "process," and "strength grade") to reflect its importance in project matching. During this process, the function systematically iterates through each key-value pair in the first list item feature dictionary. For each feature, for example, with a key of "component" and a value of "rectangular beam," the function checks the matching item feature dictionary for the same key "component." If so, the matching item feature dictionary compares the two values. A feature is considered a match only if the same key exists in both dictionaries and the corresponding values ​​are identical. Once a feature is confirmed as a match, the function accumulates the weight corresponding to that feature type in the weight mapping table to a matching total variable, which is initially zero. After iterating through all features in the first list item feature dictionary, the function generates an accumulated total matching score. In order to make the final feature matching score a standardized value between 0 and 1, so as to facilitate subsequent weighted fusion, the function performs a normalization operation.

[0062] Furthermore, the weighted sum of the semantic similarity score and the feature matching score is calculated to obtain the final fusion score. It should be understood that although the semantic similarity score can handle synonyms and word order changes well, it may not be sensitive enough to the subtle differences in some key technical parameters (for example, the difference between C35 and C40 may not be obvious in the semantic vector); and relying solely on the feature matching score, although it is extremely strict in checking the key parameters, it cannot handle the situation where the expression is flexible but the meaning is consistent. Therefore, in the technical solution of the present invention, these two evaluation methods are fused. Here, by adjusting the weight coefficient and The system can dynamically decide whether to prioritize overall semantic compatibility or strict consistency of key features based on different engineering fields and matching accuracy requirements. This configurable fusion strategy makes the final matching results both comprehensive and controllable, achieving accuracy and adaptability far exceeding that of a single evaluation system.

[0063] Specifically, the weighted sum of the semantic similarity score and the feature matching score is calculated using the following formula to obtain the final fusion score, wherein the formula is:

[0064] in, is the semantic similarity score, is the feature matching score, and are the first weight and the second weight.

[0065] Here, the first weight is greater than the second weight, the first weight is 0.6 and the second weight is 0.4.

[0066] Specifically, S6 extracts and displays the top-three matching items from the final ranked list of matches. In practice, the system starts with the first element in the list (i.e., the element with index 0 and the highest score) and continuously extracts a specified number of elements. In this invention, this number is set to 3. Therefore, the system extracts the three elements with indexes 0, 1, and 2, forming a new sublist containing only the top three matching items.

[0067] In summary, the intelligent matching method for bill of quantities according to an embodiment of the present invention is explained. It first forms a dictionary of key features by deeply analyzing the project description, which forms the basis for subsequent precise matching; then, a two-stage process of "coarse screening-fine sorting" is adopted: in the coarse screening stage, the project codes pointing to professional classifications are combined with key features that can quickly lock the core elements, and the huge standard quota library is efficiently filtered to quickly generate a candidate matching list with controllable scale and high relevance; in the fine sorting stage, it turns to a more detailed double verification of semantics and features, comprehensively utilizing the deep semantic similarity of the complete project description text and the accurate comparison results of the key feature dictionary, and obtains the final score through fusion calculation to achieve accurate sorting of the candidate list. In this way, it can effectively overcome the semantic gap caused by synonyms, word order reversal, non-standard expressions, etc. in traditional text matching, and greatly improve the accuracy of matching.

[0068] While various embodiments of the present disclosure have been described above, the above descriptions are illustrative, non-exhaustive, and not intended to be limiting of the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or improvements to existing technologies, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for intelligent matching of bill of quantities, characterized in that: include: Structuring the original engineering bill of quantities file obtained to obtain a structured bill of quantities data table; Extracting a first list item from a structured list data table, the first list item including an item code string and an item description text; performing key feature extraction on the item description text in the first list item to obtain a first list item feature dictionary; Based on the item code character string in the first list item and the first list item feature dictionary, the standard quota library is roughly screened for a candidate set to obtain a roughly screened candidate matching list; Based on the item description text in the first list item and the first list item feature dictionary, calculating a final fusion score between the first list item and each to-be-matched item in the coarse-screened candidate matching list to obtain a final matching ranked list; Extract and display the top-3 matching items with the final fusion score from the final matching sorted list.

2. The method for intelligent matching of bill of quantities according to claim 1, characterized in that: The original engineering bill of quantities file is structured to obtain a structured bill of quantities data table, including: Performing file type identification on the original engineering bill of quantities file to obtain a file type identification result; Selecting an appropriate parser based on the file type identification result, and parsing the original bill of quantities file based on the appropriate parser to obtain the original data after preliminary parsing; Perform header positioning and column mapping on the raw data after preliminary parsing to obtain a dictionary of data row data and column mapping relationships; Based on the column mapping relationship dictionary, after data row screening and fine-grained cleaning of the data rows, structured data objects are generated to obtain a structured list data table.

3. The method for intelligent matching of bill of quantities according to claim 1, characterized in that: Key features are extracted from the item description text in the first list item to obtain a first list item feature dictionary, including: Perform regular expression matching on the project description text based on the regular expression engine to obtain regular results and text for NER; Input the text for NER into the NER model to obtain the NER result; The regularization result and the NER result are combined to obtain the first list item feature dictionary.

4. The method for intelligent matching of bill of quantities according to claim 1, characterized in that: Based on the item code string in the first list item and the first list item feature dictionary, the standard quota library is roughly screened for a candidate set to obtain a rough screening candidate matching list, including: Based on the project code string, the standard quota database is filtered hierarchically based on the code to obtain a first coarse screening candidate matching set; Based on the first list item feature dictionary, the standard quota database is subjected to reverse index filtering of core feature keywords to obtain a second coarse screening candidate matching set; An intersection operation is performed on the first coarse screening candidate matching set and the second coarse screening candidate matching set to obtain a coarse screening candidate matching list.

5. The method for intelligent matching of bill of quantities according to claim 4, characterized in that: Based on the project code string, perform code-based hierarchical filtering on the standard quota database to obtain the first coarse screening candidate matching set, including: Extract the encoding prefix of the item encoding string; Using the code prefix as the query index, the first coarse screening candidate matching set is returned from the standard quota database.

6. The method for intelligent matching of bill of quantities according to claim 4, characterized in that: Based on the first list item feature dictionary, the standard quota database is filtered by reverse indexing of core feature keywords to obtain a second coarse screening candidate matching set, including: extracting a first core keyword and a second core keyword from a first list item feature dictionary; Using the first core keyword and the second core keyword as query indexes respectively, returning a third coarse-screened candidate matching subset and a fourth coarse-screened candidate matching subset from the standard quota database; The intersection of the third coarse-screened candidate matching subset and the fourth coarse-screened candidate matching subset is taken to obtain a second coarse-screened candidate matching set.

7. The method for intelligent matching of bill of quantities according to claim 1, characterized in that: Based on the item description text in the first list item and the first list item feature dictionary, calculating a final fusion score between the first list item and each to-be-matched item in the coarse-screened candidate matching list to obtain a final matching ranked list, including: Calculating semantic similarity scores between the first list item and each to-be-matched item based on the item description text of the first list item; calculating, based on a first list item feature dictionary of the first list item, a feature matching score between the first list item and each of the items to be matched; The weighted sum of the semantic similarity score and the feature matching score is calculated to obtain the final fusion score.

8. The method for intelligent matching of bill of quantities according to claim 7, characterized in that: Calculating semantic similarity scores between the first list item and each to-be-matched item based on the item description text of the first list item includes: Performing text embedding encoding on the item description text of the first checklist item to obtain an item description text embedding encoding vector of the first checklist item; The cosine similarity between the text embedding encoding vector of the first list item description and the semantic vectors of each item to be matched is calculated as a semantic similarity score.

9. The method for intelligent matching of bill of quantities according to claim 7, characterized in that: Calculating a feature matching score between the first list item and each of the items to be matched based on the first list item feature dictionary of the first list item includes: Extract key features of each item to be matched to obtain a matching item feature dictionary; The first list item feature dictionary and the matching item feature dictionary are input into a feature matching scoring function to obtain a feature matching score.

10. The method for intelligent matching of bill of quantities according to claim 7, characterized in that: Calculating a weighted sum of the semantic similarity score and the feature matching score to obtain a final fusion score includes calculating a weighted sum of the semantic similarity score and the feature matching score to obtain a final fusion score using the following formula, wherein the formula is: in, is the semantic similarity score, is the feature matching score, and are the first weight and the second weight.

Images