Method and apparatus for accelerating building drawing retrieval based on virtual query matching

Abstract

This disclosure presents an embodiment of a method and apparatus for accelerating architectural drawing retrieval based on virtual query matching. One specific implementation of the method includes: acquiring textual metadata of architectural drawings, and performing multi-perspective semantic description generation processing on the textual metadata; performing structured attribute extraction processing on the multi-perspective structured description text; generating a virtual query set, and performing hierarchical processing on the virtual query set; vectorizing the hierarchical virtual query index set, and storing the virtual query vectors of each level into corresponding vector library partitions; performing parallel matching retrieval of user queries with the virtual query vectors of each level; aggregating and expanding the links of each hit virtual query set, and sorting the candidate drawing entries; and pushing the set of hit drawing entries to the target client. This implementation can achieve pre-generation and online matching based on virtual queries, thereby reducing online retrieval latency and computational overhead.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and specifically to a method and apparatus for accelerating architectural drawing retrieval based on virtual query matching. Background Technology

[0002] Currently, architectural drawing retrieval is a frequent requirement in architectural design, construction, and operation and maintenance. However, existing retrieval solutions organize drawing libraries as static files oriented towards human reading, without pre-constructing structured descriptions for machine consumption. To achieve architectural drawing retrieval, common methods include: keyword retrieval based on textual metadata, semantic retrieval based on vector embedding, or re-ranking using a large language model after recall.

[0003] However, when using the above method to retrieve architectural drawings, the following technical problems often arise: The textual metadata of the drawings is sparse and has cross-domain semantic differences with the user's query language, which leads to unstable vector retrieval recall. Each query requires repeated semantic understanding of the candidate drawings, which causes the number of calls to the large language model to increase linearly with the number of queries, resulting in high online latency and computational overhead.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose a method and apparatus for accelerating architectural drawing retrieval based on virtual query matching, in order to solve one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a method for accelerating architectural drawing retrieval based on virtual query matching, comprising: acquiring textual metadata of architectural drawings, and performing multi-view semantic description generation processing on the textual metadata to obtain multi-view structured description text; performing structured attribute extraction processing on the multi-view structured description text to obtain attribute cards; generating a virtual query set covering multiple perspectives based on the multi-view structured description text and the attribute cards, and performing hierarchical processing on the virtual query set to generate a hierarchical virtual query index set; and performing vectorization encoding on the hierarchical virtual query index set to obtain various The system generates hierarchical virtual query vectors and stores these virtual query vectors at each level into corresponding vector library partitions. Upon receiving a user query text, it performs parallel matching and retrieval between the user query and the virtual query vectors in the vector library partitions at each level to generate a set of hit virtual queries at each level. It then performs item aggregation and link expansion processing on the hit virtual query sets at each level to obtain candidate drawings to be sorted. Finally, it performs multi-dimensional weighted sorting on these candidate drawings to generate a set of hit drawing entries and pushes this set of hit drawing entries as the search result to the target client.

[0008] Secondly, some embodiments of this disclosure provide an accelerated architectural drawing retrieval device based on virtual query matching, comprising: an acquisition and generation unit configured to acquire textual metadata of architectural drawings and perform multi-view semantic description generation processing on the textual metadata to obtain multi-view structured description text; an extraction unit configured to perform structured attribute extraction processing on the multi-view structured description text to obtain attribute cards; a generation and layering unit configured to generate a virtual query set covering multiple perspectives based on the multi-view structured description text and the attribute cards, and perform layering processing on the virtual query set to generate a layered virtual query index set; and an encoding unit configured to encode the layered virtual query index set. Vectorization encoding is performed to obtain virtual query vectors at each level, and these virtual query vectors at each level are stored in their respective vector library partitions. A retrieval unit is configured to, in response to receiving a user query text, perform parallel matching and retrieval between the user query and the virtual query vectors in the vector library partitions at each level to generate a set of hit virtual queries at each level. A push unit is configured to perform item aggregation and link expansion processing on the hit virtual query sets at each level to obtain candidate drawings to be sorted, and to perform multi-dimensional weighted sorting processing on these candidate drawings to generate a set of hit drawing entries, and to push this set of hit drawing entries as the retrieval result to the target client.

[0009] The above embodiments of this disclosure have the following beneficial effects: The virtual query matching-based architectural drawing retrieval acceleration method of some embodiments of this disclosure can realize offline pre-generation and online matching of virtual queries, thereby reducing online retrieval latency and computational overhead. Specifically, the reason for high online retrieval latency and high computational overhead is that in existing solutions, drawings are stored only as static files for human reading, lacking structured entries for machine consumption. This results in the large language model needing to perform on-site semantic understanding of the drawing metadata for each query. This understanding computation cannot be reused; if a single drawing is retrieved N times, the understanding is repeated N times, causing computational redundancy and response latency. Based on this, the virtual query matching-based architectural drawing retrieval acceleration method of some embodiments of this disclosure first obtains the textual metadata of the architectural drawings and performs multi-perspective semantic description generation processing on the aforementioned textual metadata to obtain multi-perspective structured description text. This transforms the scattered and sparse textual metadata in the drawings into structured description text oriented towards multiple professional perspectives, upgrading the machine-consumable drawing information from scattered annotations to semantically coherent multi-dimensional descriptions, providing a high-quality semantic foundation for subsequent attribute extraction and query derivation. Then, the structured attribute extraction process is performed on the aforementioned multi-perspective structured description text to obtain attribute cards. Key-value pair attribute cards are extracted from the structured description, accompanied by source annotations and confidence scores, enabling downstream programs to directly parse and verify the key attribute information of the drawings, thus improving the credibility and traceability of the attribute information. Next, based on the aforementioned multi-perspective structured description text and attribute cards, a virtual query set covering multiple perspectives is generated, and this virtual query set is then layered to generate a hierarchical virtual query index set. A virtual query set covering various potential query expressions is pre-generated and hierarchically categorized according to semantic granularity, facilitating the resolution of cross-domain semantic differences between user queries and drawing metadata in the offline stage, eliminating the semantic gap during online retrieval. Furthermore, the aforementioned hierarchical virtual query index set is vectorized to obtain virtual query vectors at each level, and these virtual query vectors at each level are stored in their respective level vector library partitions. Encoding the hierarchical virtual query index set into vectors and storing them in physically isolated partitioned vector libraries ensures the independence of queries with different semantic granularities in the vector space, avoids mutual interference caused by mixed indexes, and improves the retrieval accuracy of each layer. Furthermore, in response to receiving user query text, the user query is matched and retrieved in parallel with the virtual query vectors in the vector library partitions at each level to generate the hit virtual query set for each level. Simultaneously performing parallel approximate nearest neighbor retrieval of the user query with the four hierarchical vector library partitions significantly shortens online retrieval time and improves retrieval response speed through hierarchical parallel matching. Finally...The system performs item aggregation and link expansion on the hit virtual query sets at each level to obtain candidate drawings to be ranked. These candidate drawings are then subjected to multi-dimensional weighted ranking to generate a set of hit drawing entries. This set of hit drawing entries is then pushed to the target client as the search result. By merging hit virtual queries to drawing entries using reverse pointers and propagating along bidirectional links to recall neighboring entries, a multi-dimensional weighted ranking is performed using hierarchical weights, hit width, and link verification. This outputs a set of hit drawing entries with traceable evidence, while simultaneously reducing the computational overhead of repetitive semantics. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0011] Figure 1 This is a flowchart of some embodiments of the method for accelerating architectural drawing retrieval based on virtual query matching according to the present disclosure; Figure 2 This is a schematic diagram of the structure of some embodiments of the architectural drawing retrieval acceleration device based on virtual query matching according to the present disclosure. Detailed Implementation

[0012] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0013] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0014] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0015] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0016] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0017] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0018] refer to Figure 1 The flowchart 100 illustrates some embodiments of the virtual query matching-based architectural drawing retrieval acceleration method according to the present disclosure. This virtual query matching-based architectural drawing retrieval acceleration method includes the following steps: Step 101: Obtain the textual metadata of the architectural drawings and perform multi-perspective semantic description generation processing on the textual metadata to obtain multi-perspective structured description text.

[0019] In some embodiments, the execution entity (e.g., an electronic device) of the above-described accelerated architectural drawing retrieval method based on virtual query matching can be hardware or software. When the computing device is hardware, it can be implemented as a distributed cluster composed of multiple servers or terminal devices, or as a single server or a single terminal device. When the computing device is software, it can be installed in the hardware devices listed above. It can be implemented as multiple software programs or software modules to provide distributed services, or as a single software program or software module. No specific limitations are made here.

[0020] In other embodiments, the aforementioned executing entity can acquire the textual metadata of architectural drawings and perform multi-perspective semantic description generation processing on the textual metadata to obtain multi-perspective structured descriptive text. The architectural drawings can be digital files of various architectural engineering drawings, such as CAD format files, PDF format files, or BIM model files. The textual metadata of the architectural drawings can be a set of structured and semi-structured data extracted from the architectural drawing files, carrying drawing information in text form. For example, the textual metadata of the architectural drawings can include title information, drawing annotation text, technical specifications, and file-level metadata. The title information can be a formatted field located in the title bar at the lower right corner of the drawing. For example, the title information can be the project name "a residential project," the drawing number "Construction-01," and the design stage "Construction Drawing." The drawing annotation text can be various annotation texts distributed on the drawing surface. For example, the drawing annotation text can be the room name "Master Bedroom" and the dimension annotation "2400×3600." The aforementioned technical specifications can be design specification text blocks or material preparation tables included in the drawings. For example, the aforementioned technical specifications could be "The exterior wall uses 200mm thick aerated concrete blocks, with a 50mm thick extruded polystyrene board insulation layer applied externally."

[0021] In some optional implementations of certain embodiments, the aforementioned execution entity can obtain textual metadata of architectural drawings and perform multi-perspective semantic description generation processing on the aforementioned textual metadata to obtain multi-perspective structured description text, which may include the following steps: The first step is to obtain the textual metadata of the architectural drawings. This textual metadata includes title information, drawing annotations, technical specifications, and file-level metadata. In practice, firstly, text entities are read from CAD format drawings using a CAD parsing library, and from PDF format drawings, text is extracted using the PDF text layer or recognized by an OCR engine. Then, the read text is categorized by source into three types: title information, drawing annotations, and technical specifications. Finally, combined with file-level metadata such as filename, file format, and file size read from the operating system, the above four types of data are aggregated into a complete set of textual metadata.

[0022] The second step involves generating structured descriptive text for each perspective based on the aforementioned textual metadata and predefined multiple perspective descriptions, and merging these structured descriptive texts into a multi-perspective structured descriptive text. The multi-perspective semantic description generation process can be the process of generating structured descriptive text for each perspective based on the textual metadata and predefined multiple perspective descriptions. For example, this process could generate an architectural perspective description of "two elevators and four units per floor" and a structural perspective description of "shear wall structural system" for the same standard floor plan. The predefined multiple perspective descriptions can be pre-defined descriptive instructions for multiple professional angles. For example, these predefined multiple perspective descriptions could be architectural perspective, structural perspective, machine angle, construction perspective, review perspective, cost perspective, and owner perspective. The structured descriptive text corresponding to each perspective can be a drawing description presented in declarative sentence form generated for each professional perspective. For example, the structured descriptive text corresponding to each perspective could be an architectural perspective description such as "This drawing is a standard floor plan of a residential project, adopting a two-elevator, four-unit layout, with unit combinations including 89 square meter three-bedroom and 110 square meter three-bedroom units." In practice, firstly, the aforementioned textual metadata is combined with seven predefined perspective descriptions to generate descriptive prompts. Each perspective description specifies the focus and descriptive style for that professional role. Then, the combined prompts are input into a large language model (e.g., GPT-4 series models, Claude series models, or Wenxin large model). The large language model then generates a descriptive text in statement form for each perspective on the same drawing. Finally, the structured descriptive texts corresponding to each perspective are merged into a complete multi-perspective structured descriptive text and stored in the drawing entry for subsequent offline processing. For example, combining the textual metadata and perspective descriptions of the aforementioned residential standard floor plan and inputting them into the large language model yields multiple perspective descriptions, such as "This drawing is a standard floor plan of a residential project in a science and technology park in a certain city, using a two-elevator, four-unit layout" (architectural perspective description), and "This drawing shows a compact three-bedroom unit suitable for first-time homebuyers." These descriptions are then merged to form the multi-perspective structured descriptive text for the drawing.

[0023] Step 102: Perform structured attribute extraction processing on the multi-perspective structured description text to obtain attribute cards.

[0024] In some embodiments, the aforementioned execution entity can perform structured attribute extraction processing on the aforementioned multi-view structured description text to obtain attribute cards. This structured attribute extraction processing can be a process of extracting and organizing key attribute information from the multi-view structured description text. For example, it can be extracting "Project Type: Residential," "Unit Type: Three-Bedroom," and "Layout: Two Elevators, Four Units" from the architectural perspective description. The attribute cards can be a collection of structured attributes of the drawing stored in key-value pair format. For example, the attribute card could be {"Project Type": "Residential," "Floor": "Standard Floor," "Specialty": "Architecture," "Unit Type": "89 Square Meters Three-Bedroom"}.

[0025] In some optional implementations of certain embodiments, the execution entity may perform structured attribute extraction processing on the multi-perspective structured description text to obtain attribute cards, which may include the following steps: The first step involves extracting fields from the multi-perspective structured description text to generate basic attribute fields for the drawings. This field extraction can be the process of identifying and separating attribute fields with independent semantic meaning from the structured description text. For example, it could be extracting "Project Type: Residential" and "Floor: Standard Floor" from "This drawing is a standard floor plan of a residential project." The basic attribute fields for the drawings can be unorganized raw attribute data initially extracted from the description text. For example, the basic attribute fields could be "Project Type: Residential Project," "Floor: Standard Floor," and "Structural Form: Shear Wall." In practice, the multi-perspective structured description text is first segmented into sentences or semantic units. Then, for each semantic unit, key information elements are identified, such as project type, floor, specialty, component list, and key parameters. Finally, the identified information elements are extracted as temporary fields to obtain the set of basic attribute fields for the drawings.

[0026] The second step involves standardizing and encapsulating the basic attribute fields of the drawings based on a preset attribute template, resulting in raw attribute cards in key-value pair format. This standardization and encapsulation process can be the conversion of extracted basic attribute fields into a unified key-value pair structure according to the preset template. The preset attribute template can be a predefined set of mapping rules between standard field names, data types, and value specifications. For example, the preset attribute template could define the standard field "project_type" as corresponding to "project type," with value specifications of "residential / commercial / industrial." The key-value pair format can be a data organization method where "field name: field value" appears in pairs. For example, the key-value pair format could be "floor_count: 18" indicating 18 floors, and "structure_type: shear_wall" indicating a shear wall structure. The raw attribute cards can be a set of initial attribute key-value pairs that have been standardized and encapsulated but have not yet been labeled with confidence levels. The raw attribute cards could be {"project_type": "residential", "floor": "standard", "room_count": "three-bedroom"}. In practice, firstly, a preset attribute template is loaded, which defines standard field names, data types, and value specifications. Then, the basic drawing attribute fields extracted in the first step are mapped one by one to the standard field names in the template, and non-standard expressions are standardized. Finally, the standardized fields are encapsulated as key-value pairs of "field name: field value" to obtain the original attribute card.

[0027] The third step involves determining the source and self-assessing the confidence level of each field within the original attribute cards to generate attribute cards. Each attribute card includes a source label and a confidence level value. The source label can be a marker indicating the source type of the attribute field value, suggesting whether the value is directly extracted from metadata or inferred from the model. For example, the source label could be "explicitly given in metadata" or "inferred (using a large language model)". The confidence level value can be a quantitative score of the credibility of each field in the attribute card, ranging from [0.0, 1.0]. In practice, firstly, each field in the original attribute card and its corresponding multi-perspective structured descriptive text are input into the large language model. Then, the source type of the field value is determined: if the field value directly appears in the title, label, or explanatory text, it is "explicitly given in metadata"; otherwise, it is "inferred from the model". Finally, the confidence score is output according to the source type. The values ​​explicitly given by the metadata are [0.90, 1.0], and the values ​​inferred are [0.60, 0.80]. The source label and confidence score are then appended to each field to obtain the final attribute card.

[0028] Step 103: Based on the multi-perspective structured description text and attribute cards, generate a virtual query set covering multiple perspectives, and perform hierarchical processing on the virtual query set to generate a hierarchical virtual query index set.

[0029] In some embodiments, the execution entity can generate a virtual query set covering multiple perspectives based on the multi-perspective structured description text and the attribute cards, and perform hierarchical processing on the virtual query set to generate a hierarchical virtual query index set. The virtual query set can be a pre-generated offline text set covering various potential user query expressions. For example, the virtual query set can include expressions such as "standard floor plan," "which image is the standard floor," and "please find the architectural floor plan of the standard floor." The hierarchical processing can be a process of dividing the virtual query into four levels—shallow, intermediate, deep, and task—according to semantic granularity. For example, the hierarchical processing can classify "standard floor plan" into the shallow level and "two-elevator, four-unit standard floor plan" into the intermediate level. The hierarchical virtual query index set can be a virtual query data structure organized hierarchically and labeled with hierarchical tags and entry identifiers. For example, the hierarchical virtual query index set can be a shallow index {"standard floor plan" -> entry ID: 001} and an intermediate index {"two-elevator, four-unit standard floor" -> entry ID: 001}.

[0030] In addressing the technical challenges mentioned above, and considering the application scenario—large architectural design institutes or engineering companies possessing massive amounts of historical architectural drawings—designers frequently need to retrieve specific drawings using natural language queries in their daily work. This often presents the following technical problems: each retrieval involves real-time calls to a large language model to semantically understand the user query and perform cross-domain matching with the drawing's metadata, resulting in high computational costs and unacceptable response latency, failing to meet the high-frequency interaction requirements of engineering design scenarios. Given the specific requirements of this application scenario—to significantly reduce the number of large language model calls and computational overhead during the online phase while maintaining high retrieval accuracy, enabling architectural drawing retrieval to be completed quickly without relying on expensive GPU resources—we decided to adopt the following solution: In some optional implementations of certain embodiments, the execution entity can generate a virtual query set covering multiple perspectives based on the multi-perspective structured description text and the attribute cards, and perform hierarchical processing on the virtual query set to generate a hierarchical virtual query index set, which may include the following steps: The first step is to generate first query samples corresponding to each professional perspective based on the aforementioned multi-view structured description text. These first query samples can be basic query samples generated for each professional perspective based on the multi-view structured description text. For example, the first query samples could be a "standard floor plan" generated from the architectural perspective and a "shear wall structural layout" generated from the structural perspective. In practice, firstly, the description text for each perspective in the multi-view structured description text is traversed. Then, the description text for each perspective is concatenated with the perspective name and input into the large language model, which instructs the model to generate several possible user query expressions for that perspective. Finally, all query samples output by the large language model are collected to obtain the set of first query samples corresponding to each professional perspective.

[0031] The second step involves comparing the differences between the attribute cards and the cross-project similar drawings in the preset association clue table to generate a second query sample. The preset association clue table can be a pre-defined data table recording known relationships between drawings. For example, the preset cross-project similar drawings could be drawing entries with similar functions or forms in different projects. For instance, the cross-project similar drawings could be the "standard floor plan" of Project A and the "standard floor plan" of Project B being similar drawings. The association clue table can record the floor plan correspondence between "Architectural Design-02" and "Structural Design-05" belonging to the same building. The difference comparison can be a process of comparing the attribute differences of adjacent or similar entries and generating a difference list. For example, the difference comparison can compare the standard floors of Project A and Project B and find that "the number of elevators is different: Project A has 2 elevators, Project B has 3 elevators." The second query sample can be a negative or comparative query sample generated based on the differences. For example, the second query sample could be "find a standard floor with 2 elevators, not 3." In practice, firstly, the entry IDs of cross-project similar drawings that are related to the current drawing are read from a pre-defined association clue table. Then, the attribute cards of the current drawing and the similar drawings are compared field by field, identifying fields with different attribute values ​​and generating a list of differences. Finally, the list of differences is input into a large language model, which generates negative and comparative query samples to obtain a second query sample. For example, the current drawing's attribute card has "elevator_count: 2", while the similar drawing's attribute card has "elevator_count: 3", the difference being "different number of elevators". Inputting the difference into the large language model generates a second query sample: "Find a standard floor plan with 2 elevators, not 3" and "Which standard floor has only 2 elevators instead of 3?"

[0032] The third step involves generating a third query sample based on a preset architectural business task template and the aforementioned attribute cards. The preset architectural business task template can be a predefined set of query templates for common architectural business tasks; for example, it could be "Calculate the area of ​​all standard floors in a project" or "Find all MEP drawings that conflict with a certain drawing." The third query sample can be a task-based query sample generated based on the task template and attribute cards; for example, it could be "Calculate the total building area of ​​all standard floor plans in this project." In practice, first, a list of task templates suitable for the current drawing type is read from the preset architectural business task template library. Then, each task template is concatenated with the attribute card of the current drawing and input into the large language model, instructing the model to generate a specific task-based query sample. Finally, all task-based query samples output by the large language model are collected to obtain the third query sample.

[0033] The fourth step involves summarizing and merging the first, second, and third query samples corresponding to each professional perspective to obtain an initial virtual query set. This initial virtual query set can be the complete set of unhierarchical virtual queries after merging the first, second, and third query samples. For example, the initial virtual query set could contain 1000 virtual query texts from different perspectives and generation methods. In practice, firstly, the first query sample generated in the first step, the second query sample generated in the second step, and the third query sample generated in the third step are placed in the same set container. Then, completely duplicate query texts are removed from the set, retaining only the unique query samples after deduplication. Finally, the source type of each query sample is recorded to obtain the initial virtual query set.

[0034] The fifth step involves semantic granularity partitioning of the initial virtual query set to obtain multiple query subsets. These subsets include shallow, mid-level, deep, and task-level query subsets. Semantic granularity partitioning can be a process of dividing virtual queries into different semantic levels based on information density and abstraction. For example, it could classify "standard floor plan" as a shallow subset and "standard floor plan of 89 square meters three-bedroom apartment with two elevators and four units" as a mid-level subset. The shallow query subset can be a collection of keyword-level queries containing single words or phrases that highly overlap with the terminology used in drawing annotations. For example, it could include "standard floor plan," "A-03 drawing," and "shear wall detail." The mid-level query subset can be a collection of queries containing combinations of two or more attribute fields that express multi-dimensional filtering intent. For example, it could include "89 square meter three-bedroom standard floor plan" and "standard floor plan of the 18th floor of a residential project." The aforementioned deep query subset can be a collection of queries that describe usage scenarios or business intentions in natural language and do not directly use drawing annotation terms. For example, the deep query subset may include "compact three-bedroom apartment suitable for school district positioning" or "exterior wall insulation construction drawings required for energy conservation review." The aforementioned task-level query subset can be a collection of queries that are based on task packages or workflows, are usually initiated by an Agent, and require the return of a set of drawings rather than a single drawing. For example, the task-level query subset may include "the complete set of drawings required to prepare a construction support package for a residential project" or "the reference drawing set required to complete a fire safety compliance review." In practice, firstly, the text content of each query sample in the initial virtual query set is obtained. Then, the queries are automatically categorized according to their complexity and information detail: single words or phrases are categorized as shallow, combinations of two or more attributes as mid-level, natural language scenario descriptions as deep, and task package levels as task-level. Finally, each query sample is assigned to its corresponding query subset, resulting in shallow query subsets, mid-level query subsets, deep query subsets, and task-level query subsets.

[0035] Step 6: Match each query sample in the above multiple query subsets with the corresponding level label and the corresponding drawing item identifier to obtain labeled hierarchical query data. The level label can be a category identifier marking the level to which each virtual query belongs; for example, the level label could be "shallow", "middle", "deep", or "task". The corresponding drawing item identifier can be a unique ID number identifying a drawing item; for example, the corresponding drawing item identifier could be "PROJ-A_BLDG-01_STD-FLOOR_ARCH-002". The labeled hierarchical query data can be the data structure after attaching the level label and item identifier to each virtual query. For example, the labeled hierarchical query data could be {"query": "Standard Floor Plan", "level": "shallow", "item_id": "PROJ-A_BLDG-01_STD-FLOOR_ARCH-002"}. In practice, first, a level label field is added to each query sample, with the label value being the level name of its subset. Next, an item identifier field is added to each query sample to indicate which drawing the query sample originates from. Finally, the query samples with added hierarchy labels and item identifiers are saved as a complete record, resulting in labeled hierarchical query data.

[0036] The seventh step involves partitioning and aggregating the labeled hierarchical query data to generate a hierarchical virtual query index set. In practice, firstly, the labeled hierarchical query data is divided into four groups according to the hierarchical labels, with each group corresponding to a hierarchical level. Then, within each group, a secondary sort is performed based on the identifier of the corresponding drawing item for easy location during subsequent retrieval. Finally, the four groups are stored as independent index partitions, with each partition containing all virtual queries and their associated information for that level, resulting in the hierarchical virtual query index set.

[0037] The above-described steps, as an inventive point of this disclosure, solve the technical problem mentioned in the background: "Real-time invocation of a large language model to perform semantic understanding of user queries and cross-domain matching with drawing metadata for each retrieval leads to high computational costs and unacceptable response delays, failing to meet the high-frequency interaction requirements in engineering design scenarios." The reasons for this technical problem are as follows: Traditional solutions place the understanding computation of the large language model in the online retrieval stage. Each user query requires the large language model to re-understand the user's intent and semantically align with the drawing metadata. This "online repetitive understanding" mode leads to wasted computational resources and response speed bottlenecks. The present invention pre-generates basic query samples covering multiple perspectives, counterfactual comparison query samples based on attribute difference points, and task-type query samples based on task templates in the offline stage, and organizes them into an index set hierarchically according to semantic granularity. This achieves one-time digestion of cross-domain semantic differences in the offline stage, transforming online retrieval into same-domain matching, ensuring stable hits for negative queries through explicit pre-generated anchor points, and enabling Agent-level task-level retrieval to directly match the task-level index. This saves the cost of repeated invocation of the large language model and the online computational overhead of cross-domain semantic matching in the online retrieval stage.

[0038] Step 104: Vectorize the hierarchical virtual query index set to obtain virtual query vectors for each level, and store the virtual query vectors for each level into the corresponding vector library partitions for each level.

[0039] In some embodiments, the execution entity can perform vectorization encoding on the hierarchical virtual query index set to obtain virtual query vectors for each level, and store the virtual query vectors for each level into the corresponding vector library partitions for each level. The vectorization encoding can be a process of converting text data into high-dimensional numerical vectors through an embedding model. For example, the vectorization encoding can encode the query text "standard layer plan view" into a 1536-dimensional floating-point vector using the text-embedding-ada-002 model. The virtual query vectors for each level can be vector data obtained by vectorizing the virtual query texts corresponding to the shallow, middle, deep, and task levels respectively. For example, the virtual query vectors for each level can include the "standard layer plan view" vector in the shallow vector library and the "compact three-bedroom layout suitable for first-time homebuyers" vector in the deep vector library. The vector library partitions at each of the above levels can be physical or logical storage areas that store vector data independently according to hierarchical labels. For example, the vector library partitions at each of the above levels can include four independent partitions: shallow vector library partition, medium vector library partition, deep vector library partition, and task layer vector library partition.

[0040] In some optional implementations of certain embodiments, the execution entity may perform vectorized encoding on the hierarchical virtual query index set to obtain virtual query vectors for each level, and store the virtual query vectors for each level into the corresponding vector library partitions for each level, which may include the following steps: The first step is to encode each query text in the hierarchical virtual query index set to generate a hierarchical virtual query original vector set. This hierarchical virtual query original vector set can be a collection of unnormalized raw vectors obtained by vectorizing all query texts in the hierarchical virtual query index set. For example, it could contain raw vectors from 100 shallow queries, 80 mid-level queries, 60 deep queries, and 40 task-level queries. In practice, first, all query texts at each level of the hierarchical virtual query index set are obtained. Then, each query text is vectorized using the same pre-trained embedding model (e.g., the text-embedding-ada-002 model), converting each query text into a fixed-dimensional numerical vector. Finally, the vectors corresponding to all level query texts are collected to generate the hierarchical virtual query original vector set. In practice, first, all raw vectors at each level of the hierarchical virtual query original vector set are obtained. Then, L2 norm normalization is performed on each original vector within the same level. This involves taking the square root of the sum of the squares of the values ​​in each dimension of the vector and using it as the divisor. Each dimension value of the vector is then divided by this divisor. Finally, the normalized vectors are grouped according to their original levels to obtain the corresponding hierarchical standardized virtual query vector set.

[0041] The second step involves performing normalization on each virtual query vector at the same level within the hierarchical virtual query vector set, resulting in the corresponding hierarchical standardized virtual query vector set. This normalization can be achieved by scaling the values ​​of each dimension of the vector to a unit length or a uniform range. For example, the normalization can normalize the original vector (0.6, 0.8) to a unit vector (0.6, 0.8) with a modulus of 1, making subsequent cosine similarity calculation equivalent to inner product calculation. The corresponding hierarchical standardized virtual query vector set can be a set of standardized vectors obtained after normalizing the original virtual query vectors at each level. For example, the corresponding hierarchical standardized virtual query vector set could contain 100 standardized vectors for the shallow layer, 80 standardized vectors for the middle layer, 60 standardized vectors for the deep layer, and 40 standardized vectors for the task layer. In practice, firstly, all original vectors at each level within the hierarchical virtual query vector set are obtained. Then, L2 norm normalization is performed on each original vector within the same level. This involves taking the square root of the sum of the squares of the values ​​in each dimension of the vector and using it as the divisor. Each dimension value of the vector is then divided by this divisor. Finally, the normalized vectors are grouped according to their original levels to obtain the corresponding hierarchical standardized virtual query vector set.

[0042] The third step involves binding auxiliary tags to each standardized virtual query vector in the aforementioned hierarchical standardized virtual query vector set to generate a vector dataset with auxiliary tags. These auxiliary tags include a hierarchical label, a drawing entry ID, and query confidence information. This vector dataset with auxiliary tags can be a complete data structure formed by binding hierarchical labels, drawing entry IDs, and query confidence information to each standardized virtual query vector. The hierarchical label can be a classification tag identifying the level to which the virtual query belongs; for example, it could be "shallow," "medium," "deep," or "task level." The drawing entry ID can be a unique identifier for a drawing entry, used to associate the virtual query with the corresponding drawing entry; for example, the drawing entry ID could be "DWG-2024-00321." The query confidence information can be a numerical value reflecting the semantic relevance between the virtual query and its source drawing; for example, the query confidence information could be 0.95 when directly derived from a multi-view description and 0.78 when inferred from attribute cards. In practice, firstly, each standardized virtual query vector and its corresponding query text are obtained from the hierarchical standardized virtual query vector set. Then, based on the record of the query text in the hierarchical virtual query index set, its corresponding hierarchical label, drawing item ID, and query confidence information are found. Finally, the hierarchical label, drawing item ID, and query confidence information are bound as auxiliary tags to the standardized virtual query vector, generating a vector dataset with auxiliary tags.

[0043] The fourth step involves grouping and splitting each labeled vector data in the aforementioned labeled vector dataset according to the hierarchical labels, resulting in hierarchical vector data for each level. This grouping and splitting process can involve dividing the labeled vector dataset into different hierarchical groups based on the hierarchical labels. For example, all vector data labeled "shallow" can be grouped into the shallow group, and all vector data labeled "deep" into the deep group. The hierarchical vector data for each level can be independent sets of vector data obtained after the grouping and splitting process. For instance, the hierarchical vector data for each level could include 100 vector data in the shallow group, 80 vector data in the middle group, 60 vector data in the deep group, and 40 vector data in the task-level group. In practice, first, all labeled vector data and their hierarchical labels are obtained from the labeled vector dataset. Then, all vector data are classified according to the hierarchical labels, with vector data having the same hierarchical label grouped into the same group. Finally, shallow layer grouped vector data, mid-layer grouped vector data, deep layer grouped vector data, and task layer grouped vector data are obtained respectively, serving as hierarchical vector data for each level.

[0044] The fifth step involves writing the hierarchical vector data for each level to its corresponding vector library partition. In practice, first, the hierarchical vector data for each level obtained in step four and its corresponding level affiliation are acquired. Then, based on the level labels of the hierarchical vector data for each level, the corresponding target vector library partition is determined. Shallow data is written to the shallow vector library partition, mid-level data to the mid-level vector library partition, and so on. Finally, the hierarchical vector data for each level is persistently stored in its corresponding vector library partition.

[0045] The sixth step involves constructing an approximate nearest neighbor index for each vector library partition to complete the storage. In practice, firstly, the vector data already written to each level of the vector library partition is retrieved. Then, an approximate nearest neighbor index (e.g., an HNSW index or an IVF index) is constructed for the vector data in each partition to support efficient similarity retrieval. Finally, the constructed indexes are persistently stored in each vector library partition, completing the storage of the hierarchical vector library. For example, an HNSW graph index is constructed for the 100 vector data entries written to the shallow vector library partition, allowing subsequent searches to quickly find the top-K most similar virtual query vectors without traversing all the data.

[0046] Step 105: In response to receiving the user query text, perform parallel matching and retrieval of the user query with the virtual query vectors in the vector library partitions at each level to generate the hit virtual query set at each level.

[0047] In some embodiments, the execution entity may, in response to receiving a user query text, perform parallel matching retrieval of the user query against virtual query vectors in the vector library partitions at each level to generate a set of hit virtual queries at each level. The user query text may be a natural language statement or keyword combination input by the user for retrieving drawings; for example, the user query text may be "compact three-bedroom apartment suitable for first-time homebuyers" or "standard floor plan". The parallel matching retrieval may involve simultaneously sending the same user query vector to multiple vector library partitions for independent similarity calculation and returning the retrieval results separately. For example, the parallel matching retrieval may involve simultaneously sending the user query vector to four vector library partitions—shallow, mid-level, deep, and task-level—for retrieval. The hit virtual query sets at each of the above levels can be the collections of virtual queries with the highest similarity to the user query, retrieved from the vector library partitions of the shallow, medium, deep, and task layers respectively. For example, the hit virtual query sets at each of the above levels can include shallow hits for "standard floor plan", medium hits for "89 square meter three-bedroom standard floor", deep hits for "compact apartment type suitable for first-time homebuyers", and task hits for "drawings required for preparing construction support packages for a residential project".

[0048] In addressing the technical challenges of the aforementioned background technologies, and considering the specific application scenario—an architectural design firm's drawing library containing hundreds of thousands of drawings—different user roles (designers, construction workers, review experts, and AI agents) employ different granularities of language for retrieval (e.g., some input keywords, some input natural language scene descriptions, and some submit requests on a task-by-task basis). This often leads to the following technical issues: user queries use everyday natural language, while drawing metadata uses engineering annotation language. Significant differences exist in the vocabulary distribution and granularity of these two languages. Single-level matching cannot simultaneously cover all the needs of keyword retrieval, fuzzy scene retrieval, and agent task retrieval, wasting time and computational resources. Given the following requirements for this application scenario: to eliminate cross-domain semantic differences between user query language and drawing index language while maintaining high retrieval accuracy, ensuring that synonymous queries using different expressions consistently hit the target drawings, and controlling the computational cost and response latency of online retrieval, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the execution entity may, in response to receiving a user query text, perform parallel matching and retrieval of the user query against the virtual query vectors in the vector library partitions at each level to generate a hit virtual query set at each level, which may include the following steps: The first step is to receive the user's query text, which can be a natural language description or a combination of keywords. The natural language description can be a query expressing the search intent in a complete sentence, such as "finding a compact three-bedroom standard floor apartment suitable for a school district." The keyword combination can be a query expressing the search intent by concatenating one or more keywords, such as "two elevators, four units per floor, standard floor with shear walls." In practice, first, the query text data input by the user from the target client is obtained. Then, the query text is formatted to confirm it is in the form of a natural language description or a combination of keywords, and leading and trailing whitespace is removed. Finally, the validated query text is used as input data for subsequent processing. For example, receiving the user's query text "compact three-bedroom apartment suitable for first-time homebuyers" is validated as a valid natural language description.

[0049] The second step involves vectorizing the user query text to generate a user query vector. The encoding method for the user query text is the same as that used for the hierarchical virtual query index set. This user query vector can be a high-dimensional numerical vector converted from the user query text using an embedding model. For example, it could be a 1536-dimensional floating-point vector obtained by encoding the query text "standard layer planar diagram" using the text-embedding-ada-002 model. In practice, first, the user query text received in the first step is obtained. Then, the user query text is vectorized using the same pre-determined embedding model (e.g., the text-embedding-ada-002 model). This embedding model is the same as the one used to encode the hierarchical virtual query index set, ensuring that the query vector and the vectors in the database reside in the same vector space. Finally, the encoding result is output as the user query vector. For example, the query text "compact three-bedroom apartment suitable for first-time homebuyers" is encoded into a 1536-dimensional floating-point vector using the text-embedding-ada-002 model.

[0050] The third step is to simultaneously send the user query vectors to the shallow vector library partition, the medium vector library partition, the deep vector library partition, and the task layer vector library partition in each of the above vector library partitions to perform parallel matching retrieval.

[0051] Fourth, for each level's corresponding vector library partition, perform the following steps: Sub-step one involves determining the cosine similarity between the user query vector and each virtual query vector in the corresponding vector library partition of the aforementioned level, to generate a cosine similarity set. This cosine similarity set can be a collection of all similarity values ​​obtained after calculating the cosine similarity between the user query vector and each virtual query vector in a vector library partition. For example, the cosine similarity set could include {"Standard Floor Plan": 0.95, "A-03 Drawing": 0.87, "Shear Wall Detail": 0.72}. The hit virtual query set can be a set of a predetermined number of virtual queries and their similarity scores selected from a vector library partition, sorted by cosine similarity from high to low. For example, the hit virtual query set could include {"Standard Floor Plan": 0.95, "Two-Standard Floor with Four Units per Floor": 0.92, "18-Story Standard Floor Plan": 0.88}. In practice, firstly, the user query vector and each virtual query vector stored in the current level vector library partition are obtained. Then, the cosine similarity between the user query vector and each virtual query vector is calculated one by one. The cosine similarity measures the semantic similarity by calculating the cosine of the angle between the two vectors; the closer the value is to 1, the more similar they are. Finally, each virtual query vector and its corresponding cosine similarity value are combined into a cosine similarity set. For example, in the current level vector library partition, the cosine similarity between the user query vector and the "standard floor plan" vector is 0.95, the cosine similarity with the "two-elevator four-unit standard floor" vector is 0.92, and the cosine similarity with the "18-story standard floor plan" vector is 0.88, resulting in the cosine similarity set {"standard floor plan": 0.95, "two-elevator four-unit standard floor": 0.92, "18-story standard floor plan": 0.88}.

[0052] Sub-step two involves sorting the cosine similarity set in descending order to generate the hit virtual query set for the aforementioned level. In practice, first, the cosine similarity set generated in sub-step one is obtained. Then, all virtual queries in the cosine similarity set are sorted in descending order according to their cosine similarity values. Finally, a predetermined number of virtual queries (e.g., the first 20) and their similarity scores are selected as the hit virtual query set for the current level. For example, after sorting the cosine similarity set {"Standard Floor Plan": 0.95, "Two Elevators, Four Units Standard Floor": 0.92, "18-Floor Standard Floor Plan": 0.88} in descending order, the first 3 are taken to obtain the hit virtual query set {"Standard Floor Plan": 0.95, "Two Elevators, Four Units Standard Floor": 0.92, "18-Floor Standard Floor Plan": 0.88}.

[0053] The fifth step is to generate the hit virtual query sets for each level. In practice, firstly, the hit virtual query sets and their corresponding level labels returned by the four vector library partitions (shallow, middle, deep, and task level) in step four are collected. Then, the hit virtual query sets of each partition are categorized and organized according to the level labels. Finally, the hit virtual query sets of each level are combined into a single hit virtual query set for each level, which serves as input for subsequent item aggregation and link expansion processing. For example, the shallow level returns {"standard floor plan": 0.95}, the middle level returns {"89 square meter three-bedroom standard floor": 0.93}, the deep level returns {"compact apartment suitable for first-time homebuyers": 0.91}, and the task level returns {"drawings required for preparing construction support packages for a residential project": 0.87}. After merging, the complete hit virtual query sets for each level are obtained.

[0054] The above-described steps, as an inventive point of this disclosure, solve the technical problem mentioned in the background: "User queries use everyday natural language, while drawing metadata uses engineering annotation language. The vocabulary distribution and expression granularity of the two differ significantly, and a single-level matching cannot simultaneously cover all the needs of keyword retrieval, fuzzy scene retrieval, and Agent task retrieval, wasting time and computing resources." The reasons for this technical problem are as follows: User queries use everyday natural language, while drawing metadata uses engineering annotation language. The vocabulary distribution and expression granularity of the two differ significantly, and a single fixed matching level cannot adapt to the expression habits and retrieval intentions of different users. This invention addresses this by storing the hierarchical virtual query index in four independent vector library partitions. During online retrieval, the user query vector is simultaneously and in parallel sent to the four partitions for independent approximate nearest neighbor retrieval. This achieves simultaneous matching of the same query at different semantic granularities, with each level independently returning hit results. This eliminates the impact of cross-domain semantic differences on recall stability, covering all retrieval needs at the keyword level, attribute combination level, scene intent level, and Agent task level. It also saves the computational overhead and latency required for query semantic understanding and cross-domain matching of the large language model during the online retrieval phase.

[0055] Step 106: Perform item aggregation and link expansion processing on the hit virtual query sets at each level to obtain candidate items of drawings to be sorted, and perform multi-dimensional weighted sorting processing on the candidate items of drawings to be sorted to generate a set of hit drawing items, and push the set of hit drawing items as the search result to the target client.

[0056] In some embodiments, the execution entity can perform item aggregation and link expansion processing on the hit virtual query sets at each level to obtain candidate drawing entries to be sorted, and perform multi-dimensional weighted sorting processing on the candidate drawing entries to generate a set of hit drawing entries, and push the set of hit drawing entries as the retrieval result to the target client. Item aggregation can be a process of merging hit virtual queries at each level into corresponding drawing entries based on their bound drawing entry IDs. For example, item aggregation can be merging the "DWG-2024-00321" bound to the shallow hit "Standard Floor Plan" and the same "DWG-2024-00321" bound to the mid-level hit "89 square meter three-bedroom standard floor" into the same drawing entry. Link expansion can be a process of searching for related neighboring entries from a hit entry along a bidirectional link table stored within the drawing entry. For example, link expansion can be finding the corresponding staircase detail entry from a standard floor plan entry along the "detail reference" link. The aforementioned candidate drawings to be ranked can be a set of drawing entries obtained after entry aggregation and link expansion, awaiting multi-dimensional weighted ranking. For example, the aforementioned candidate drawings to be ranked can include the 5 drawings initially matched by aggregation and the 3 neighboring drawings recalled by link expansion. The aforementioned multi-dimensional weighted ranking can be a processing method that comprehensively scores and ranks candidate entries by integrating weight signals from multiple independent dimensions. For example, the aforementioned multi-dimensional weighted ranking can calculate the final score by integrating three dimensions: hierarchical matching weight, multi-level hit reward weight, and link mutual verification topology weight. The aforementioned multiple dimensions can refer to multiple independent weighting signal sources on which the ranking is based. For example, the aforementioned multiple dimensions can include hierarchical weight dimension, hit width reward dimension, and link mutual verification topology weight dimension. The aforementioned set of matched drawing entries can be an ordered list of drawing entries output after multi-dimensional weighted ranking, with each entry accompanied by structured traceability evidence. For example, the aforementioned set of matched drawing entries can be 5 drawing entries arranged from high to low in comprehensive score and their corresponding matching evidence. The target client mentioned above can be a terminal device or downstream application that receives the search results. For example, the target client can be a web browser, a mobile app, or an AIAgent system.

[0057] In addressing the technical challenges of the aforementioned background technologies, and considering the specific application scenario—an architectural design firm's drawing library containing hundreds of thousands of drawings—users not only need to find individual matching drawings during retrieval but also require the system to utilize the referencing relationships between drawings for navigational expansion and recall. This often leads to the following technical problems: even when hierarchical vector retrieval yields virtual queries at each level, these results are scattered across different levels, with overlaps and omissions among the returned drawing entries. Furthermore, the referencing relationships between drawings are not utilized, resulting in additional reasoning costs, wasted computational and data resources, and incomplete, poorly ordered, and uninterpretable search results. To address the specific requirements of this application scenario—namely, the need for efficient aggregation of scattered results across different levels, full utilization of the referencing topology relationships between drawings for expansion and recall, comprehensive consideration of multiple sorting signals to generate accurate sorting, and the inclusion of traceable retrieval evidence—we have decided to adopt the following solution: In some optional implementations of certain embodiments, the execution entity may perform item aggregation and link expansion processing on the hit virtual query sets at each level to obtain candidate items for drawing to be sorted, and perform multi-dimensional weighted sorting processing on the candidate items for drawing to be sorted to generate a set of hit drawing items, and push the set of hit drawing items as the search result to the target client, which may include the following steps: The first step involves performing an entry merging process on the drawing entry IDs bound to each virtual query in the hit virtual query sets at each level, to generate an initial aggregated drawing entry set. The drawing entry ID can be a unique identifier for a drawing entry, used to associate a virtual query with its corresponding drawing entry. For example, the drawing entry ID could be "DWG-2024-00321". The entry merging process can be a procedure that combines hit virtual queries with the same drawing entry ID into the same drawing entry. For example, the entry merging process can combine "DWG-2024-00321" contained in both shallow and medium-level hits into a single drawing entry record. The initial aggregated drawing entry set can be a collection of all hit drawing entries obtained after the entry merging process. For example, the initial aggregated drawing entry set could contain 3 drawings hit at the shallow level and 4 drawings hit at the medium level, resulting in a total of 6 drawings after deduplication. In practice, firstly, the hit virtual query sets for each level are obtained, and the drawing item ID bound to each hit virtual query is extracted. Then, hit virtual queries with the same drawing item ID are merged into the same drawing item, recording which levels the item was hit at and the similarity score for each level. Finally, all hit drawing items are collected to generate an initial aggregated drawing item set. For example, a shallow hit "Standard Floor Plan" is bound to "DWG-2024-00321," and a mid-level hit "89 square meter three-bedroom standard floor plan" is bound to the same "DWG-2024-00321." These two hits are merged into the drawing item "DWG-2024-00321," recording that it was hit by both the shallow and mid-level hits.

[0058] The second step involves using the bidirectional link table stored within each initial aggregated drawing entry in the aforementioned initial aggregated drawing entry set to perform a finite-step expansion process along the links, resulting in an expanded drawing candidate entry set. The bidirectional link table can be a complete list of forward and reverse links stored in the drawing entries, with each link having a type and strength value. For example, the bidirectional link table could include a "detail reference" link from the current entry to a detail drawing and "similar floor plan" reverse links from other entries to the current entry. The finite-step expansion process can be a neighbor lookup operation within a limited number of steps along the bidirectional link table. For example, it could involve expanding one step along the link from the current entry to find its directly associated neighbor drawing entries. The expanded drawing candidate entry set can be a collection of all neighbor drawing entries obtained through the link expansion process. For example, the expanded drawing candidate set could include five neighbor drawings obtained by expanding along the links from the six drawings initially aggregated. In practice, firstly, the bidirectional link table stored in each drawing entry of the initial aggregated drawing entry set is obtained. This table records the forward links from the current entry to other entries and the reverse links from other entries to the current entry. Each link has a type and strength value. Then, an expansion step is performed along links with a strength higher than a preset threshold (e.g., 0.5) to find the linked neighboring drawing entries. Finally, all the expanded neighboring drawing entries are collected to generate a candidate set of expanded drawing entries. For example, from the bidirectional link table of drawing entry "DWG-2024-00321", the "detail reference" link strength pointing to "DWG-2024-00320" is read to have a strength of 0.95. Expanding along this link yields the neighboring drawing entry "DWG-2024-00320".

[0059] The third step involves merging and deduplicating the initial aggregated drawing entry set and the extended drawing candidate entry set to obtain a set of candidate drawings to be sorted. This set can be the complete set of candidate entries obtained by merging the initial aggregated drawing entry set and the extended drawing candidate entry set, after deduplication. For example, the set could be 9 drawings obtained by merging and deduplicating the initial aggregated set of 6 drawings and the extended set of 5 neighboring drawings. In practice, first, the initial aggregated drawing entry set and the extended drawing candidate entry set are obtained. Then, the two sets are merged, and duplicate entries with the same drawing entry ID are deduplicated, retaining only one record. Finally, the merged and deduplicated set of drawing entries is used as the set of candidate drawings to be sorted. For example, if the initial aggregated drawing entry set has 5 drawings, and the extended set has 3 neighboring drawings (one of which is already in the initial aggregated set), merging and deduplicating results in a set of 7 candidate drawings to be sorted.

[0060] Fourth, for each candidate drawing item in the above set of candidate drawings to be sorted, perform the following steps: Sub-step one involves determining the hierarchical matching weight, multi-level hit reward weight, and link verification topology weight corresponding to the candidate drawings to be sorted, in order to generate comprehensive weighted information for the entries. The hierarchical matching weight can be different weight values ​​assigned based on the hit level, with the shallow level having the lowest, the middle level the next highest, the deep level the highest, and the task level the highest. For example, the hierarchical matching weight could be 0.3 for the shallow level, 0.6 for the middle level, 0.8 for the deep level, and 1.0 for the task level. The multi-level hit reward weight can be an extra bonus weight given when the same drawing is hit at multiple levels simultaneously. For example, the multi-level hit reward weight could be a bonus of 0.2 when a drawing is hit at both the middle and deep levels. The link verification topology weight can be the topology verification weight value obtained when a candidate entry is jointly pointed to by multiple hit entries through links. For example, the link verification topology weight could be a topology weight of 0.15 when an entry is simultaneously pointed to by three hit entries. The aforementioned comprehensive weighted information can be a comprehensive score generated by combining hierarchical matching weight, multi-level hit reward weight, and link verification topology weight. For example, the comprehensive weighted information could be an item's total score equal to 1.05, calculated as: hierarchical matching weight 0.7 + hit reward 0.2 + verification weight 0.15. In practice, firstly, the hierarchical hit record for each item in the candidate item set of drawings to be sorted is obtained, including which levels the item is hit at and the similarity score of each level. The hierarchical matching weight is assigned according to the rule of lowest for shallow levels, middle levels, higher for deep levels, and highest for task levels. Then, it is determined whether the item is hit at multiple levels simultaneously; if so, a hit width reward weight is given. Finally, it is determined whether the item is jointly pointed to by multiple hit items through links; if so, a link verification topology weight is given. The comprehensive weighted information of the item is generated by combining the weights of the above three dimensions. For example, if an entry is hit by both the middle and deep layers, its level matching weight is 0.7, its hit width bonus weight is 0.2, and it is pointed to by two other hit entries, its link mutual verification topology weight is 0.15, and its total weighted score is 1.05.

[0061] The fifth step involves sorting the candidate drawing entries based on the comprehensive weighted information of each entry, resulting in an ordered sequence of drawing entries. This ordered sequence can be a list of drawing entries arranged from highest to lowest comprehensive weighted score; for example, it could be [Entry A: 1.05, Entry B: 0.92, Entry C: 0.88, ...]. In practice, first, the comprehensive weighted information of each entry in the candidate drawing entry set is obtained. Then, all candidate entries are sorted in descending order of their comprehensive weighted scores. Finally, the sorted result is output as the ordered sequence of drawing entries. For example, seven candidate entries arranged from highest to lowest comprehensive score are: Entry A (1.05), Entry B (0.92), Entry C (0.88), ..., Entry G (0.45), resulting in the ordered sequence of drawing entries.

[0062] Step 6: Based on the ordered sequence of drawing entries, generate a set of matching drawing entries with structured source evidence. This structured source evidence can be machine-resolvable evidence data containing the match query, hit level, link propagation path, and attribute field confidence. For example, the structured source evidence could be {match_query: "89 square meters three-bedroom standard floor", layer: "middle floor", confidence: 0.92, source: "architectural perspective description"}. In practice, first, obtain the match query text, hit level, link propagation path, and attribute field confidence information for each entry in the ordered sequence of drawing entries. Then, generate a piece of structured evidence for each entry, including the match query text, the hit level, whether it was included via link propagation, the link path, relevant fields in the attribute card, and their confidence. Finally, attach the evidence to the corresponding entry in both natural language and structured field formats to generate a set of matching drawing entries with structured source evidence. For example, generate natural language evidence for a certain entry: "Matches query '89 square meters three-bedroom standard floor' (middle layer), confidence 0.92, derived from the architectural perspective description of this image", and generate the structured fields {match_query: "89 square meters three-bedroom standard floor", layer: "middle layer", confidence: 0.92, source: "architectural perspective description"}.

[0063] The seventh step involves formatting and encapsulating the aforementioned set of matched drawing entries before pushing it to the target client. In practice, this involves first obtaining the set of matched drawing entries with structured traceability evidence. Then, the data is formatted and encapsulated according to the target client's requirements, converting the set of matched drawing entries into a data format that the target client can parse. Finally, the encapsulated data is pushed to the target client. For example, the set of matched drawing entries can be encapsulated as JSON format data and pushed to the web frontend or AI Agent system via an HTTP interface.

[0064] The above-described steps, as an inventive point of this disclosure, solve the technical problem mentioned in the background: "Even if hierarchical vector retrieval obtains virtual queries at each level, these results are scattered across different levels, and there are overlaps and omissions among the returned drawing entries at each level. Furthermore, the reference relationships between drawings are not utilized, leading to additional reasoning costs, wasting computational and data resources, and resulting in incomplete, irrationally ordered, and uninterpretable retrieval results." The reasons for these technical problems are as follows: In existing vector retrieval schemes, drawing entries are embedded independently into the database, without pre-established and maintained reference relationships that can be directly utilized by the retrieval system; the recall results only return drawing identifiers and similarity scores, without accompanying intermediate state information such as matching reasons, hit sources, and propagation paths, making it impossible for users and agents to verify whether the recall reasons are valid. This invention organically combines item aggregation, link expansion, and multi-dimensional weighted ranking. It utilizes "being pointed to by multiple hit items" as a topology-level mutual verification weighting signal and generates structured source evidence for each returned item, including the hit virtual query, hit level, link propagation path, and attribute field confidence. This expands the recall from single-point matching to evidence aggregation based on reference topology. The intermediate state of the recall results is visible to downstream agents, facilitating error location. Downstream agents can perform further reasoning based on the structured evidence, saving the computational overhead of downstream agents in verifying retrieval results.

[0065] The above embodiments of this disclosure have the following beneficial effects: The virtual query matching-based architectural drawing retrieval acceleration method of some embodiments of this disclosure can realize offline pre-generation and online matching of virtual queries, thereby reducing online retrieval latency and computational overhead. Specifically, the reason for high online retrieval latency and high computational overhead is that in existing solutions, drawings are stored only as static files for human reading, lacking structured entries for machine consumption. This results in the large language model needing to perform on-site semantic understanding of the drawing metadata for each query. This understanding computation cannot be reused; if a single drawing is retrieved N times, the understanding is repeated N times, causing computational redundancy and response latency. Based on this, the virtual query matching-based architectural drawing retrieval acceleration method of some embodiments of this disclosure first obtains the textual metadata of the architectural drawings and performs multi-perspective semantic description generation processing on the aforementioned textual metadata to obtain multi-perspective structured description text. This transforms the scattered and sparse textual metadata in the drawings into structured description text oriented towards multiple professional perspectives, upgrading the machine-consumable drawing information from scattered annotations to semantically coherent multi-dimensional descriptions, providing a high-quality semantic foundation for subsequent attribute extraction and query derivation. Then, the structured attribute extraction process is performed on the aforementioned multi-perspective structured description text to obtain attribute cards. Key-value pair attribute cards are extracted from the structured description, accompanied by source annotations and confidence scores, enabling downstream programs to directly parse and verify the key attribute information of the drawings, thus improving the credibility and traceability of the attribute information. Next, based on the aforementioned multi-perspective structured description text and attribute cards, a virtual query set covering multiple perspectives is generated, and this virtual query set is then layered to generate a hierarchical virtual query index set. A virtual query set covering various potential query expressions is pre-generated and hierarchically categorized according to semantic granularity, facilitating the resolution of cross-domain semantic differences between user queries and drawing metadata in the offline stage, eliminating the semantic gap during online retrieval. Furthermore, the aforementioned hierarchical virtual query index set is vectorized to obtain virtual query vectors at each level, and these virtual query vectors at each level are stored in their respective level vector library partitions. Encoding the hierarchical virtual query index set into vectors and storing them in physically isolated partitioned vector libraries ensures the independence of queries with different semantic granularities in the vector space, avoids mutual interference caused by mixed indexes, and improves the retrieval accuracy of each layer. Furthermore, in response to receiving user query text, the user query is matched and retrieved in parallel with the virtual query vectors in the vector library partitions at each level to generate the hit virtual query set for each level. Simultaneously performing parallel approximate nearest neighbor retrieval of the user query with the four hierarchical vector library partitions significantly shortens online retrieval time and improves retrieval response speed through hierarchical parallel matching. Finally...The system performs item aggregation and link expansion on the hit virtual query sets at each level to obtain candidate drawings to be ranked. These candidate drawings are then subjected to multi-dimensional weighted ranking to generate a set of hit drawing entries. This set of hit drawing entries is then pushed to the target client as the search result. By merging hit virtual queries to drawing entries using reverse pointers and propagating along bidirectional links to recall neighboring entries, a multi-dimensional weighted ranking is performed using hierarchical weights, hit width, and link verification. This outputs a set of hit drawing entries with traceable evidence, while simultaneously reducing the computational overhead of repetitive semantics.

[0066] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a building drawing retrieval acceleration device based on virtual query matching. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, this virtual query matching-based architectural drawing retrieval acceleration device can be specifically applied to various electronic devices.

[0067] like Figure 2 As shown, a building drawing retrieval acceleration device 200 based on virtual query matching includes: an acquisition and generation unit 201, an extraction unit 202, a generation and layering unit 203, an encoding unit 204, a retrieval unit 205, and a push unit 206. The acquisition and generation unit 201 is configured to: acquire textual metadata of the building drawings, and perform multi-view semantic description generation processing on the textual metadata to obtain multi-view structured description text. The extraction unit 202 is configured to: perform structured attribute extraction processing on the multi-view structured description text to obtain attribute cards. The generation and layering unit 203 is configured to: generate a virtual query set covering multiple perspectives based on the multi-view structured description text and the attribute cards, and perform layering processing on the virtual query set to generate a layered virtual query index set. The encoding unit 204 is configured to: perform vectorized encoding on the layered virtual query index set to obtain virtual query vectors at each level, and store the virtual query vectors at each level into corresponding vector library partitions at each level. The retrieval unit 205 is configured to: in response to receiving a user query text, perform parallel matching retrieval of the user query against the virtual query vectors in the vector library partitions at each level to generate a set of hit virtual queries at each level. The push unit 206 is configured to: perform item aggregation and link expansion processing on the hit virtual query sets at each level to obtain candidate items for drawing to be sorted; perform multi-dimensional weighted sorting processing on the candidate items for drawing to be sorted to generate a set of hit drawing items; and push the set of hit drawing items as the retrieval result to the target client.

[0068] It is understandable that the units and references recorded in the virtual query matching-based architectural drawing retrieval acceleration device 200 are related to... Figure 1 The steps in the described method correspond accordingly. Therefore, the operations, features, and beneficial effects described above for the method also apply to the virtual query matching-based architectural drawing retrieval acceleration device 200 and the units contained therein, and will not be repeated here.

[0069] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0070] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including an acquisition and generation unit, an extraction unit, a generation and layering unit, an encoding unit, a retrieval unit, and a push unit. The names of these units do not necessarily limit the unit itself; for example, the acquisition and generation unit may also be described as "a unit that acquires textual metadata of architectural drawings and performs multi-perspective semantic description generation processing on the aforementioned textual metadata to obtain multi-perspective structured descriptive text."

[0071] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0072] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for accelerating architectural drawing retrieval based on virtual query matching, characterized in that, include: Obtain textual metadata of architectural drawings, and perform multi-perspective semantic description generation processing on the textual metadata to obtain multi-perspective structured description text; The multi-perspective structured description text is subjected to structured attribute extraction processing to obtain attribute cards; Based on the multi-perspective structured description text and the attribute cards, a virtual query set covering multiple perspectives is generated, and the virtual query set is layered to generate a layered virtual query index set. The hierarchical virtual query index set is vectorized to obtain virtual query vectors for each level, and the virtual query vectors for each level are stored in the corresponding vector library partitions for each level. In response to receiving a user query text, the user query is matched and retrieved in parallel with the virtual query vectors in the vector library partitions at each level to generate a hit virtual query set at each level. The matched virtual query sets at each level are aggregated and expanded with links to obtain candidate drawings to be sorted. The candidate drawings are then sorted using a multi-dimensional weighted sorting process to generate a set of matched drawings. Finally, the set of matched drawings is pushed to the target client as the search result.

2. The method according to claim 1, characterized in that, The process of acquiring textual metadata of architectural drawings and generating multi-perspective semantic descriptions from the textual metadata to obtain multi-perspective structured description text includes: Obtain textual metadata of architectural drawings, including title information, drawing annotation text, technical specifications, and document-level metadata; Based on the text metadata and predefined multiple perspective description information, structured description text corresponding to each perspective is generated, and the structured description text corresponding to each perspective is merged into a multi-perspective structured description text.

3. The method according to claim 1, characterized in that, The step of extracting structured attributes from the multi-perspective structured description text to obtain attribute cards includes: The multi-view structured description text is processed to extract fields to generate basic attribute fields for the drawing; Based on the preset attribute template, the basic attribute fields of the drawing are standardized and encapsulated to obtain the original attribute cards in key-value pair form; The source determination and confidence self-assessment are performed on each field in the original attribute card to generate an attribute card, which includes a source label and a confidence value.

4. The method according to claim 1, characterized in that, The step of vectorizing the hierarchical virtual query index set to obtain virtual query vectors for each level, and storing the virtual query vectors for each level into the corresponding vector library partitions for each level, includes: Each query text in the hierarchical virtual query index set is encoded to generate a hierarchical virtual query original vector set; Normalization is performed on each virtual query original vector at the same level in the hierarchical virtual query original vector set to obtain the corresponding hierarchical standardized virtual query vector set. For each standardized virtual query vector in the hierarchical standardized virtual query vector set, an auxiliary tag is bound to generate a vector dataset with auxiliary tags, the auxiliary tags including hierarchical labels, drawing item IDs and query confidence information; Based on the hierarchical labels, each labeled vector data in the labeled vector dataset is grouped and split to obtain hierarchical vector data at each level; Write the hierarchical vector data of each level into the corresponding vector library partition of each level; For each vector library partition, perform an approximate nearest neighbor index building process to complete the storage.

5. A building drawing retrieval acceleration device based on virtual query matching, characterized in that, include: The acquisition and generation unit is configured to acquire textual metadata of architectural drawings and perform multi-perspective semantic description generation processing on the textual metadata to obtain multi-perspective structured description text. The extraction unit is configured to perform structured attribute extraction processing on the multi-perspective structured description text to obtain attribute cards; The generation and hierarchical unit is configured to generate a virtual query set covering multiple perspectives based on the multi-perspective structured description text and the attribute cards, and to perform hierarchical processing on the virtual query set to generate a hierarchical virtual query index set. The encoding unit is configured to perform vectorized encoding on the hierarchical virtual query index set to obtain virtual query vectors for each level, and to store the virtual query vectors for each level into the corresponding vector library partitions for each level. The retrieval unit is configured to, in response to receiving a user query text, perform parallel matching and retrieval of the user query with the virtual query vectors in the vector library partitions at each level to generate a hit virtual query set at each level. The push unit is configured to perform item aggregation and link expansion processing on the hit virtual query sets at each level to obtain candidate items of drawings to be sorted, and to perform multi-dimensional weighted sorting processing on the candidate items of drawings to be sorted to generate a set of hit drawing items, and to push the set of hit drawing items as the search result to the target client.

Images