Patent retrieval type generation method based on general large model

Abstract

The invention relates to the technical field of data processing, and discloses a universal large model-based patent retrieval type generation method, which comprises the following steps of: acquiring enterprise data, and configuring retrieval channels, an enterprise internal institution title extension word list and a technical field extension word list; calling a first model to extract the natural language retrieval demand data to obtain an initial keyword; expanding the selected query channel and the initial keyword to obtain a target channel lexicon expanded word and a target self-defined lexicon expanded word; calling a second model to generate a final keyword set; calling a query interface based on the selected query channel to obtain a retrieval rule corresponding to the query channel, and calling a third model to generate a patent retrieval formula; and executing the patent retrieval formula and formatting a retrieval result. By implementing the method and the device, the problem that all related technologies cannot meet the comprehensive requirements of low-threshold operation, high-precision matching, customized requirement adaptation and dynamic word bank updating in patent retrieval is solved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a patent search query generation method based on a general large model. Background Technology

[0002] In intellectual property management and technological innovation activities, patent search is a core step in acquiring technical information, avoiding infringement risks, and identifying R&D directions. However, with the explosive growth of patent data and the deepening segmentation of technological fields, traditional patent search methods are no longer sufficient to meet the needs for efficient and accurate searches. Currently, there are two main implementation methods in the field of patent search: one is the traditional conditional search method, which is further subdivided into simple search and advanced search. Simple search only provides query entry points for basic fields such as patent application number, applicant, and invention name. Users initiate searches through single or a few combinations of conditions. Although it is easy to operate, the query dimensions are limited and cannot cover the complex multi-dimensional search needs of surveying and mapping archive patents. Advanced search, while supporting multi-field combination queries and search expression writing, can construct complex query conditions through logical operators, theoretically improving search accuracy. However, the operation threshold is extremely high, and ordinary technical personnel need to undergo systematic training to use it proficiently, which greatly limits search efficiency and accessibility.

[0003] Another type is the retrieval method based on artificial intelligence semantic recognition. This method uses machine learning models to semantically encode patent text, calculates the similarity between the user's query and the full text of the patent, and then returns related results. Although this type of method solves the limitations of literal keyword matching in traditional retrieval and can identify some synonyms or near-synonyms, it still has significant shortcomings in patent retrieval scenarios. It cannot customize the retrieval logic according to the internal business needs of the enterprise. For example, when an enterprise needs to search for "topographical mapping archive patents related to internal R&D project A", the model cannot associate the internal organizational names, such as "R&D center A" with "a certain laboratory", or the technical field classification, such as "project A technical direction" with the subordinate technology of "remote sensing data processing", resulting in a disconnect between the retrieval results and the actual needs.

[0004] Furthermore, both traditional and existing semantic searches suffer from outdated terminology and fragmented search processes. Patent terminology is updated rapidly, while existing search systems often use statically configured terminologies, failing to dynamically synchronize the latest terms and relationships. Simultaneously, each step in the search process is independent, requiring manual coordination by the user. For example, users must first convert their natural language requirements into keywords, then write search queries according to channel rules, and finally manually execute the search and compile the results. This cumbersome process is prone to human error, leading to missed search criteria and further reducing search efficiency and accuracy.

[0005] In summary, none of the relevant technologies can meet the comprehensive needs of patent retrieval, including low-barrier operation, high-precision matching, customized adaptation, and dynamic thesaurus updates. Summary of the Invention

[0006] In view of this, the present invention provides a patent retrieval generation method based on a general large model to solve the problem that related technologies cannot meet the comprehensive needs of low-threshold operation, high-precision matching, customized demand adaptation, and dynamic thesaurus update in patent retrieval.

[0007] This invention provides a patent search expression generation method based on a general large model. The method includes: acquiring enterprise data; configuring channel information tables and search rule tables for each search channel based on the enterprise data, as well as extended terminology tables for internal organizational names and technical fields; receiving natural language search requirement data and selected query channels input by the user; calling a first model to extract the natural language search requirement data to obtain initial keywords; expanding the selected query channels and initial keywords to obtain target channel terminology and target custom terminology; calling a second model to generate a final keyword set based on the natural language search requirement data, initial keywords, target channel terminology, and target custom terminology; calling a query interface based on the selected query channel to obtain the corresponding query channel's search rules; calling a third model to combine the natural language search requirement data, the final keyword set, and the search rules to generate a patent search expression; executing the patent search expression and formatting the search results; and returning the patent search expression and formatted search results to the user.

[0008] The patent search query generation method based on a general large model provided in this embodiment firstly establishes a standardized and customized basic data support system for the subsequent patent search process by acquiring enterprise data and configuring channel information tables and search rule tables for each search channel, as well as extended thesaurus of internal organizational names and technical fields. The channel information tables for each search channel clearly define key information such as calling parameters and verification methods for different channels, avoiding call failures or parameter errors caused by inconsistent channel information. The search rule tables standardize the search query syntax and logical requirements for each channel in advance, providing a basis for generating search queries that conform to channel specifications. The enterprise-specific thesaurus incorporates unique organizational names and technical field classifications, making the search process more aligned with the enterprise's actual business scenarios. Secondly, by receiving natural language search request data and selected query channels input by users, the method directly connects with the user's original search intent, breaking the dependence of traditional searches on professional operations. Users don't need to learn complex search condition settings or search query writing rules; they only need to describe their search needs in natural language, similar to everyday conversation, and choose familiar or frequently used query channels. This significantly lowers the barrier to entry for patent searches, allowing users with different knowledge backgrounds to quickly initiate search requests and improving the convenience and user experience of the search operation. Then, the first model extracts initial keywords from the natural language search request data, achieving accurate parsing and core information extraction of the user's natural language needs. Leveraging its understanding of the semantics of the patent field, the first model filters out key content related to patent searches, such as technical terms, institution names, and technical directions, from the user's potentially redundant natural language descriptions. This avoids the omission of core information due to subjective judgment bias or insufficient professional knowledge during manual keyword extraction, ensuring that the initial keywords accurately reflect the user's core search needs. Subsequently, by expanding the selected query channels and initial keywords, target channel thesaurus expansion words and target custom thesaurus expansion words are obtained, enriching the coverage of search keywords and improving the comprehensiveness of the search. Based on the channel-specific thesaurus expanded with selected query channels, industry-wide synonyms, hypernyms, and hyponyms accumulated by those channels can be incorporated to compensate for the insufficient coverage of diverse technical expressions by single keywords. Custom-defined thesaurus expanded with internal enterprise terms can supplement the company's proprietary terminology and related vocabulary, ensuring the keyword system encompasses both industry commonalities and company characteristics, effectively reducing the omission of relevant patents due to differences in terminology. Furthermore, by calling a second model based on natural language retrieval demand data, initial keywords, target channel thesaurus expanded terms, and target custom-defined thesaurus expanded terms, a final keyword set is generated, enabling precise filtering and optimization of expanded terms.The second model combines the context of the user's natural language needs to determine the semantic relevance of each expanded term to the initial keywords, eliminating irrelevant or weakly related expanded terms to avoid redundant search scope caused by invalid expanded terms. Simultaneously, it systematically integrates effective expanded terms to form a logically clear and precisely covered final keyword set, ensuring that the subsequently generated search queries focus on the user's core needs and improve the relevance of search results. Next, by calling the query interface based on the selected query channel to obtain the corresponding query rules, and calling the third model to combine the natural language search requirement data, the final keyword set, and the search rules to generate patent search queries, ensures that the generated search queries conform to the technical specifications of the specific channel, improving the effectiveness and adaptability of the search queries. The query interface can obtain the latest search rules from each channel in real time, avoiding search query failures due to untimely rule updates; the third model can deeply integrate user needs, keywords, and channel rules, automatically constructing grammatically correct and logically rigorous search queries without requiring manual formatting adjustments or addition of logical operators, significantly improving the efficiency and accuracy of search query generation. Finally, by executing the patent search query and formatting the search results, the system returns the patent search query and the formatted search results to the user, providing a complete and clear search output and improving the usability of the search results. Executing the search query directly connects to the query channel to obtain the original search data, ensuring the timeliness and completeness of the results; formatting organizes the original data in a structured way, highlighting key information such as patent names, abstracts, and core clauses, facilitating quick browsing and filtering for users; simultaneously, the generated search query is returned, allowing users to further adjust and optimize it according to their actual needs, achieving dual transparency in both the search results and the search process, enhancing user trust in the search results and ease of use. By implementing this invention, the system solves the problem that related technologies cannot meet the comprehensive needs of low-threshold operation, high-precision matching, customized adaptation, and dynamic thesaurus updates in patent retrieval.

[0009] In one optional implementation, the channel information table includes channel name, channel code, channel type, invocation method, request address, verification information, and invocation parameters. The channel type is divided into advanced search type and thesaurus type. The invocation method includes Hypertext Transfer Protocol invocation method and WebSocket protocol invocation method. The search rule table contains the search syntax specifications, field matching rules, and logical operator usage rules for each search channel.

[0010] In one alternative implementation, the first model is characterized as a general large model pre-trained and optimized from a patent domain corpus.

[0011] In one optional implementation, the selected query channel and initial keywords are expanded to obtain target channel terminology extensions and target custom terminology extensions. This includes: calling a query interface through a code node to query the channel information table, determining whether the query channel has a terminology query interface configured, and if so, calling the terminology query interface and inputting the initial keywords to obtain the organization extensions and technology extensions corresponding to the initial keywords in the channel terminology, and using the organization extensions and technology extensions as target channel terminology extensions; calling a query interface through a code node to check whether the enterprise has a custom terminology query interface configured, and if so, calling the custom terminology query interface and inputting the initial keywords to obtain the organization title extensions corresponding to the initial keywords from the enterprise's internal organization title extensions table and the technology extensions corresponding to the initial keywords from the enterprise's internal technology extensions table, and using the organization title extensions and technology extensions as target custom terminology extensions; and performing deduplication on the target channel terminology extensions and target custom terminology extensions to obtain deduplicated target channel terminology extensions and target custom terminology extensions.

[0012] In one optional implementation, the second model is a large-parameter general-purpose model with a parameter scale of 10 billion. The second model has a built-in semantic similarity calculation module and a surveying and mapping terminology context understanding module. The semantic similarity calculation module uses the cosine similarity algorithm to calculate the relevance between the target channel terminology extension words and the target custom terminology extension words and the initial keywords, respectively. The surveying and mapping terminology context understanding module combines the scenario description in the natural language retrieval requirement data to determine the applicability of the target channel terminology extension words and the target custom terminology extension words in the surveying and mapping archive retrieval scenario.

[0013] In one optional implementation, the third model is a large-parameter general model with a parameter scale of 20 billion. The third model adapts to the retrieval syntax of different query channels through a retrieval rule transfer learning module. The retrieval rule transfer learning module transforms the retrieval syntax specifications, field matching rules and logical operator usage rules of each query channel into vector representations.

[0014] In one alternative implementation, the first model, the second model, and the third model share the enterprise data knowledge graph.

[0015] In one optional implementation, the second model supports user-defined extended term filtering rules, which include technical field priority, relevance to organization name, and term timeliness.

[0016] In one optional implementation, after obtaining the retrieval rules for the selected query channel by calling the query interface, and generating the patent search formula by calling the third model in combination with natural language retrieval demand data, the final keyword set, and the retrieval rules, the method further includes:

[0017] The third model performs syntax and logic checks through a retrieval validity verification module. The syntax check matches the retrieval syntax specification of the corresponding query channel, and the logic check detects the reasonableness of the nesting of logical operators in the retrieval expression.

[0018] If the verification passes, the patent search query will be output.

[0019] If the verification fails, readjust the keyword combination and logical relationship of the patent search query until the verification passes.

[0020] In an optional implementation, the method further includes: controlling the first model, the second model, and the third model to output processing logs, the processing logs including model call times, input parameters, intermediate results, and output results, and storing the processing logs in association with the generated patent search formulas and search results. Attached Figure Description

[0021] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating a patent retrieval method based on a general large model according to an embodiment of the present invention. Detailed Implementation

[0023] In intellectual property management and technological innovation activities, patent search is a core step in acquiring technical information, avoiding infringement risks, and identifying R&D directions. However, with the explosive growth of patent data and the deepening segmentation of technological fields, traditional patent search methods are no longer sufficient to meet the needs for efficient and accurate searches. Currently, there are two main implementation methods in the field of patent search: one is the traditional conditional search method, which is further subdivided into simple search and advanced search. Simple search only provides query entry points for basic fields such as patent application number, applicant, and invention name. Users initiate searches through single or a few combinations of conditions. Although it is easy to operate, the query dimensions are limited and cannot cover the complex multi-dimensional search needs of surveying and mapping archive patents. Advanced search, while supporting multi-field combination queries and search expression writing, can construct complex query conditions through logical operators, theoretically improving search accuracy. However, the operation threshold is extremely high, and ordinary technical personnel need to undergo systematic training to use it proficiently, which greatly limits search efficiency and accessibility.

[0024] Another type is the retrieval method based on artificial intelligence semantic recognition. This method uses machine learning models to semantically encode patent text, calculates the similarity between the user's query and the full text of the patent, and then returns related results. Although this type of method solves the limitations of literal keyword matching in traditional retrieval and can identify some synonyms or near-synonyms, it still has significant shortcomings in patent retrieval scenarios. It cannot customize the retrieval logic according to the internal business needs of the enterprise. For example, when an enterprise needs to search for "topographical mapping archive patents related to internal R&D project A", the model cannot associate the internal organizational names, such as "R&D center A" with "a certain laboratory", or the technical field classification, such as "project A technical direction" with the subordinate technology of "remote sensing data processing", resulting in a disconnect between the retrieval results and the actual needs.

[0025] Furthermore, both traditional and existing semantic searches suffer from outdated terminology and fragmented search processes. Patent terminology is updated rapidly, while existing search systems often use statically configured terminologies, failing to dynamically synchronize the latest terms and relationships. Simultaneously, each step in the search process is independent, requiring manual coordination by the user. For example, users must first convert their natural language requirements into keywords, then write search queries according to channel rules, and finally manually execute the search and compile the results. This cumbersome process is prone to human error, leading to missed search criteria and further reducing search efficiency and accuracy.

[0026] In summary, none of the relevant technologies can meet the comprehensive needs of patent retrieval, including low-barrier operation, high-precision matching, customized adaptation, and dynamic thesaurus updates.

[0027] This invention provides a patent search expression generation method based on a general large model. The method includes: acquiring enterprise data; configuring channel information tables and search rule tables for each search channel based on the enterprise data, as well as extended terminology tables for internal organizational names and technical fields; receiving natural language search requirement data and selected query channels input by the user; calling a first model to extract the natural language search requirement data to obtain initial keywords; expanding the selected query channels and initial keywords to obtain target channel terminology and target custom terminology; calling a second model to generate a final keyword set based on the natural language search requirement data, initial keywords, target channel terminology, and target custom terminology; calling a query interface based on the selected query channel to obtain the corresponding query channel's search rules; calling a third model to combine the natural language search requirement data, the final keyword set, and the search rules to generate a patent search expression; executing the patent search expression and formatting the search results; and returning the patent search expression and formatted search results to the user.

[0028] The patent search query generation method based on a general large model provided in this embodiment firstly establishes a standardized and customized basic data support system for the subsequent patent search process by acquiring enterprise data and configuring channel information tables and search rule tables for each search channel, as well as extended thesaurus of internal organizational names and technical fields. The channel information tables for each search channel clearly define key information such as calling parameters and verification methods for different channels, avoiding call failures or parameter errors caused by inconsistent channel information. The search rule tables standardize the search query syntax and logical requirements for each channel in advance, providing a basis for generating search queries that conform to channel specifications. The enterprise-specific thesaurus incorporates unique organizational names and technical field classifications, making the search process more aligned with the enterprise's actual business scenarios. Secondly, by receiving natural language search request data and selected query channels input by users, the method directly connects with the user's original search intent, breaking the dependence of traditional searches on professional operations. Users don't need to learn complex search condition settings or search query writing rules; they only need to describe their search needs in natural language, similar to everyday conversation, and choose familiar or frequently used query channels. This significantly lowers the barrier to entry for patent searches, allowing users with different knowledge backgrounds to quickly initiate search requests and improving the convenience and user experience of the search operation. Then, the first model extracts initial keywords from the natural language search request data, achieving accurate parsing and core information extraction of the user's natural language needs. Leveraging its understanding of the semantics of the patent field, the first model filters out key content related to patent searches, such as technical terms, institution names, and technical directions, from the user's potentially redundant natural language descriptions. This avoids the omission of core information due to subjective judgment bias or insufficient professional knowledge during manual keyword extraction, ensuring that the initial keywords accurately reflect the user's core search needs. Subsequently, by expanding the selected query channels and initial keywords, target channel thesaurus expansion words and target custom thesaurus expansion words are obtained, enriching the coverage of search keywords and improving the comprehensiveness of the search. Based on the channel-specific thesaurus expanded with selected query channels, industry-wide synonyms, hypernyms, and hyponyms accumulated by those channels can be incorporated to compensate for the insufficient coverage of diverse technical expressions by single keywords. Custom-defined thesaurus expanded with internal enterprise terms can supplement the company's proprietary terminology and related vocabulary, ensuring the keyword system encompasses both industry commonalities and company characteristics, effectively reducing the omission of relevant patents due to differences in terminology. Furthermore, by calling a second model based on natural language retrieval demand data, initial keywords, target channel thesaurus expanded terms, and target custom-defined thesaurus expanded terms, a final keyword set is generated, enabling precise filtering and optimization of expanded terms.The second model combines the context of the user's natural language needs to determine the semantic relevance of each expanded term to the initial keywords, eliminating irrelevant or weakly related expanded terms to avoid redundant search scope caused by invalid expanded terms. Simultaneously, it systematically integrates effective expanded terms to form a logically clear and precisely covered final keyword set, ensuring that the subsequently generated search queries focus on the user's core needs and improve the relevance of search results. Next, by calling the query interface based on the selected query channel to obtain the corresponding query rules, and calling the third model to combine the natural language search requirement data, the final keyword set, and the search rules to generate patent search queries, ensures that the generated search queries conform to the technical specifications of the specific channel, improving the effectiveness and adaptability of the search queries. The query interface can obtain the latest search rules from each channel in real time, avoiding search query failures due to untimely rule updates; the third model can deeply integrate user needs, keywords, and channel rules, automatically constructing grammatically correct and logically rigorous search queries without requiring manual formatting adjustments or addition of logical operators, significantly improving the efficiency and accuracy of search query generation. Finally, by executing the patent search query and formatting the search results, the system returns the patent search query and the formatted search results to the user, providing a complete and clear search output and improving the usability of the search results. Executing the search query directly connects to the query channel to obtain the original search data, ensuring the timeliness and completeness of the results; formatting organizes the original data in a structured way, highlighting key information such as patent names, abstracts, and core clauses, facilitating quick browsing and filtering for users; simultaneously, the generated search query is returned, allowing users to further adjust and optimize it according to their actual needs, achieving dual transparency in both the search results and the search process, enhancing user trust in the search results and ease of use. By implementing this invention, the system solves the problem that related technologies cannot meet the comprehensive needs of low-threshold operation, high-precision matching, customized adaptation, and dynamic thesaurus updates in patent retrieval.

[0029] According to an embodiment of the present invention, a patent retrieval method based on a general large model is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] This embodiment provides a patent retrieval query generation method based on a general large model. Figure 1 This is a flowchart of a patent retrieval method based on a general large model according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps:

[0031] Step S101: Obtain enterprise data, and configure channel information tables and search rule tables for each search channel based on the enterprise data, as well as extended term tables for internal organizational names and technical fields.

[0032] Specifically, the channel information table includes channel name, channel code, channel type, calling method, request address, verification information, and calling parameters. The channel type is divided into advanced search type and thesaurus type. The calling method includes Hypertext Transfer Protocol calling method and WebSocket protocol calling method. The search rules table contains the search syntax specifications, field matching rules, and logical operator usage rules for each search channel.

[0033] Furthermore, when acquiring enterprise data, various basic data related to the enterprise's patent search business are collected, including information on patent search channels that the enterprise cooperates with or frequently uses, the names of various departments and organizations within the enterprise, the technical fields the enterprise focuses on, and the corresponding terminology system. When configuring the channel information table for each search channel based on the enterprise data, the specific information of each search channel needs to be entered into the channel information table one by one. Among them, the channel name is the official or internally agreed identification name of each search channel, the channel code is a unique code to distinguish different search channels, the channel type is divided into advanced search type and thesaurus type according to the core functions provided by the search channel, the calling method is determined according to the communication protocol supported by the search channel interface, namely the Hypertext Transfer Protocol calling method or the WebSocket protocol calling method, the request address is the interface address that needs to be accessed when initiating a search request, the verification information is the key, token or account password and other information required to ensure the legitimacy of the search request, and the calling parameters are the fields that need to be carried when initiating a search request and the corresponding value rules. When configuring the search rule table, for each search channel, the search syntax specifications, field matching rules, and logical operator usage rules for that channel should be compiled and entered. The search syntax specifications outline the character combinations and field identifier formats to be followed when constructing search queries. Field matching rules specify the matching methods for different search fields (such as invention title, abstract, and claims). Logical operator usage rules define the symbol representations, priority order, and usage scenario restrictions for logical operators such as "AND," "OR," and "NOT." When configuring the internal organizational terminology extension dictionary, the standard names, common abbreviations, historically used names, and related organizational names of each internal organization should be compiled and entered into the dictionary according to organizational category, establishing the correspondence between organizational names. When configuring the internal technical field extension dictionary, the core terms, related terms, superior terms, and subordinate terms of each technical field should be compiled based on the company's R&D direction and business scope. The technical relationships between terms should be clarified and entered into the dictionary to ensure that terminology expansion can be achieved based on the dictionary during subsequent searches. Meanwhile, separate data storage structures were established for the channel information table, retrieval rule table, internal organizational terminology extended terminology table, and internal technical field terminology extended terminology table to ensure the independence and accessibility of data in each table.

[0034] Step S102: Receive the user's input of natural language search request data and selected query channel.

[0035] Specifically, when receiving natural language search request data from users, an input interface conforming to user interaction habits is provided. This input interface supports text box input, allowing users to fully describe their patent search needs in natural language, including but not limited to the technical field, core technical features, relevant institution names, and application scenarios of the target patent. The input interface also features text length adaptation, automatically adjusting the display range based on the amount of user input. Users can also modify, supplement, or delete entered content to ensure accurate expression of their search intent. When receiving user-selected search channels, the interface displays the configured search channels in a list format. Each search channel's name must be clearly labeled in the list for easy identification and selection by the user. Users select a channel by clicking its name in the list. After selection, the interface clearly indicates the selected search channel through highlighting, checkmarks, or other visual indicators. If a user needs to change search channels, they can directly click on another channel name; the system automatically removes the identifier of the previously selected channel and updates it with the identifier of the newly selected channel. During the receiving process, the format of the natural language search query data entered by the user is validated to ensure that the data is in a recognizable text format. If the user enters non-text content, they should be prompted to re-enter search query data that meets the requirements. Simultaneously, the validity of the user-selected query channel must be validated to confirm that the query channel has been configured in the channel information table and is in an available state. If the user-selected channel is not configured or is unavailable, the user should be prompted to select another configured and available query channel to ensure that subsequent search processes can be conducted based on valid query channels. After receiving the natural language search query data and the selected query channel, both are linked and stored in a temporary data storage area to provide a data source for subsequent steps such as keyword extraction and thesaurus expansion.

[0036] Step S103: Call the first model to extract natural language retrieval demand data and obtain initial keywords.

[0037] Specifically, the first model is a general large model pre-trained and optimized from patent domain corpus.

[0038] Furthermore, before calling the first model, the natural language retrieval request data is preprocessed according to the input format required by the first model. The preprocessing includes filtering special characters in the natural language retrieval request data and segmenting long text content to ensure that the input data meets the text parsing requirements of the first model. After preprocessing, a call request is initiated through a pre-defined model call interface. The call request must carry the preprocessed natural language retrieval request data and the basic parameters required for model operation, including text parsing accuracy and the range of keyword extraction quantities. Upon receiving the call request, the first model first activates the patent domain semantic recognition module. This module, based on the patent domain corpus knowledge learned during pre-training, performs semantic decomposition on the natural language retrieval request data, identifying core semantic units such as the technical subject, technical action, technical effect, and limiting conditions contained within it. The patent corpus is a collection of texts covering patent documents across various technical fields, including patent specifications, claims, abstracts, and patent examination opinions. The first model, through pre-training on this corpus, has mastered the unique terminology, sentence structure, and expression logic of patent texts, enabling it to accurately distinguish between valid and redundant information related to patent retrieval in natural language search data. Based on semantic recognition, the first model initiates a keyword extraction module. This module, based on the importance ranking of semantic units, selects terms reflecting the core search requirements as candidate keywords. During the selection process, it prioritizes extracting technical field terms, core technical feature terms, related institution names, and specific technical effect terms from the natural language search data, while removing function words, modifiers, and general descriptive terms without actual search significance. After completing the candidate keyword extraction, the first model normalizes the candidate keywords, unifying synonyms and near-synonyms into standard terms commonly used in the patent field, avoiding keyword bias caused by differences in terminology. Finally, the first model extracts a number of keywords within a preset range, outputs normalized candidate keywords to form initial keywords, and returns the initial keywords to the data processing end through the model call interface, storing them in the specified keyword database.

[0039] Step S104: Expand the selected query channel and initial keywords to obtain target channel terminology expansion and target custom terminology expansion.

[0040] Specifically, step S104 includes:

[0041] Step a1: Call the query interface through the code node to query the channel information table, determine whether the query channel is configured with a thesaurus query interface. If the query channel is configured with a thesaurus query interface, call the thesaurus query interface and input the initial keyword to obtain the organization extension words and technology extension words corresponding to the initial keyword in the channel thesaurus. Use the organization extension words and technology extension words as the target channel thesaurus extension words.

[0042] Further, the code node is activated, and a query request to the channel information table is initiated through a preset query interface. The query request must include the channel code of the selected query channel to accurately locate the record corresponding to the query channel in the channel information table. After obtaining the channel information record of the query channel, the field value of whether the thesaurus query interface is configured in the record is parsed to determine whether the query channel has the thesaurus query function. If the field value shows that it is not configured, the subsequent operations of this step are terminated; if the field value shows that it is configured, the call information such as the request address, verification information and parameter format of the thesaurus query interface is extracted from the channel information record. According to the extracted call information, a thesaurus query request is constructed, the initial keyword is entered in the request, and the verification information is included to ensure the legality of the request. Then the request is sent to the thesaurus query interface. The response data returned by the interface is received, and the extended words associated with the initial keyword in the response data are parsed. Among them, the organization extended words refer to synonyms, abbreviations, former names, etc. related to the organization name in the initial keyword, and the technical field extended words refer to synonyms, higher-level technical terms, lower-level technical terms, etc. related to the technical field terms in the initial keyword. The parsed organizational and technical terminology extensions are integrated to form the target channel terminology extension, which is then stored in a temporary terminology database.

[0043] Step a2: Call the query interface through the code node to check whether the enterprise has configured a custom thesaurus query interface. If the enterprise has configured a custom thesaurus query interface, call the custom thesaurus query interface and input the initial keyword. Obtain the extended terms of organization names corresponding to the initial keyword from the enterprise's internal extended term list of organization names, and obtain the extended terms of technology fields corresponding to the initial keyword from the enterprise's internal extended term list of technology fields. Use the extended terms of organization names and extended terms of technology fields as the target custom thesaurus extended terms.

[0044] Further, the code node is activated, and a query request is initiated to check the enterprise's internal system configuration information through a preset query interface. The query request focuses on the configuration item "Whether a custom thesaurus query interface is configured" to determine whether the enterprise has the capability to call a custom thesaurus. If the query result shows that the custom thesaurus query interface is not configured, the subsequent operations of this step are terminated; if the query result shows that it is configured, key information such as the request address, call parameter format, and permission verification method of the custom thesaurus query interface is extracted from the configuration information. Based on the extracted key information, a custom thesaurus query request is constructed, initial keywords are entered in the request parameters, and the permission verification process (such as carrying the enterprise's internal authorization token) is completed. Then, the request is sent to the custom thesaurus query interface. After receiving the request, the interface queries the internal organizational terminology extension table and the internal technical terminology extension table separately: In the internal organizational terminology extension table, it matches internally specific terms related to the organizational names in the initial keywords, including departmental abbreviations, project team abbreviations, and internally agreed-upon names of collaborating institutions, forming organizational terminology extensions; in the internal technical terminology extension table, it matches internal technical expressions related to the technical terms in the initial keywords, including technical codes, technical names corresponding to R&D projects, and simplified terms commonly used in internal technical documents, forming technical terminology extensions. The organizational terminology extensions and technical terminology extensions are integrated to form the target custom terminology extension, which is stored in a temporary extension term database, separate from the target channel terminology extension obtained in step a1.

[0045] Step a3: Perform deduplication on the target channel terminology extension and the target custom terminology extension to obtain the deduplicated target channel terminology extension and target custom terminology extension.

[0046] Furthermore, target channel terminology extensions and target custom terminology extensions are extracted from the temporary extended term database. First, deduplication is performed on the target channel terminology extensions: a temporary deduplication set is constructed, and words from the target channel terminology extensions are added to the set one by one. Utilizing the uniqueness of set elements, duplicate words are automatically filtered out. After deduplication, the set is converted back to list format, yielding the internally deduplicated target channel terminology extensions. Subsequently, the same deduplication operation is performed on the target custom terminology extensions. Another temporary deduplication set is constructed, and words from the target custom terminology extensions are added one by one. After filtering out duplicate words, the set is converted back to list format, yielding the internally deduplicated target custom terminology extensions. Finally, a cross-thesaurus deduplication operation is performed: the target channel thesaurus extension words after internal deduplication are compared with the target custom thesaurus extension words, identifying and marking identical words in both sets of extension words; according to preset rules (prioritizing the retention of duplicate words in the target custom thesaurus extension words or the target channel thesaurus extension words), duplicate words in one set of thesaurus are deleted to ensure that the final target channel thesaurus extension words and the target custom thesaurus extension words have no overlap. The two sets of deduplicated extension words are then stored again in a temporary extension word database to provide extension word data support for subsequent calls to the second model to generate the final keyword set.

[0047] Step S105: The second model is invoked to generate the final keyword set based on natural language retrieval demand data, the initial keyword target channel thesaurus extension words, and the target custom thesaurus extension words.

[0048] Specifically, the second model is a large-parameter general-purpose model with a parameter scale of 10 billion. The second model has a built-in semantic similarity calculation module and a surveying and mapping terminology context understanding module. The semantic similarity calculation module uses the cosine similarity algorithm to calculate the relevance between the target channel terminology extension words and the target custom terminology extension words and the initial keywords, respectively. The surveying and mapping terminology context understanding module combines the scenario description in the natural language retrieval demand data to determine the applicability of the target channel terminology extension words and the target custom terminology extension words in the surveying and mapping archive retrieval scenario.

[0049] Furthermore, before calling the second model, the natural language retrieval requirement data, initial keywords, target channel thesaurus extensions, and target custom thesaurus extensions are integrated according to the input format required by the second model. During the integration process, various types of data need to be classified and labeled, clearly indicating the data source types of the natural language retrieval requirement data, initial keywords, target channel thesaurus extensions, and target custom thesaurus extensions, to ensure that the second model can accurately identify the attributes of different data. After the data integration is completed, a call request is initiated through the preset model call interface. In addition to carrying the integrated data, the call request also needs to configure the basic parameters required for model operation, including semantic similarity calculation threshold and context understanding accuracy level, to ensure that the model runs according to the expected logic. After receiving the call request, the second model first starts the semantic similarity calculation module. This module uses the cosine similarity algorithm to calculate the relevance between the target channel thesaurus extensions, the target custom thesaurus extensions, and the initial keywords. During the calculation process, the initial keywords and each extended term are first converted into vector form, with the vector dimension determined by the lexical representation system established during the pre-training of the second model. Then, by calculating the cosine value between different vectors, the correlation score between each extended term and the initial keyword is obtained. A higher correlation score indicates a stronger semantic connection between the extended term and the initial keyword. After calculation, the semantic similarity calculation module compares the correlation scores with a preset correlation threshold, selecting extended terms with correlation scores not lower than the threshold as candidate extended terms for further verification. Subsequently, the second model activates the surveying terminology context understanding module. This module first parses the scene descriptions in the natural language retrieval demand data, extracting relevant scene elements for surveying and mapping archive retrieval, including information such as surveying and mapping technology application scenarios, data processing requirements, and retrieval target scope. Then, the candidate extended terms are matched with the extracted scene elements to determine the applicability of each candidate extended term in the current surveying and mapping archive retrieval scenario. If a candidate extended term's expression logically conflicts with the scene elements or fails to integrate into the technical context of the current scene, it is deemed unsuitable and eliminated. Conversely, if a candidate extended term effectively relates to the scene elements and conforms to the technical expression habits of the current scene, it is deemed suitable and retained. After determining the suitability of candidate extended terms, the second model integrates the retained candidate extended terms with the initial keywords. During the integration process, the terms are categorized according to their type (technical terms, organizational names, technical features, etc.) to ensure a balanced distribution and logical clarity across all categories. Simultaneously, redundancy is checked after categorization, eliminating duplicate terms or terms with similar expressions and identical semantics. This results in a final keyword set that is structurally sound, semantically precise, and comprehensively comprehensive.The second model returns the final keyword set to the data processing end by calling the interface, and stores it in a dedicated keyword set database, providing core data support for the subsequent call to the third model to generate patent search queries.

[0050] Step S106: Based on the selected query channel, call the query interface to obtain the retrieval rules of the corresponding query channel, and call the third model to combine the natural language retrieval demand data, the final keyword set and retrieval rules to generate the patent retrieval formula.

[0051] Specifically, the third model is a large-parameter general model with a parameter scale of 20 billion. The third model adapts to the retrieval syntax of different query channels through the retrieval rule transfer learning module. The retrieval rule transfer learning module transforms the retrieval syntax specifications, field matching rules and logical operator usage rules of each query channel into vector representations.

[0052] Furthermore, when retrieving corresponding search rules by calling the query interface based on the selected query channel, the channel code of the selected query channel is first extracted from the stored channel information table. This channel code is then used as the query identifier to construct a query request for the search rule table. The query request must explicitly include the channel code and data acquisition type identifier (i.e., the search rule) and is sent to the search rule storage terminal through a pre-defined query interface. The response data returned by the search rule storage terminal is received, and the complete search rules corresponding to the selected query channel are parsed. These search rules include search expression syntax specifications, field matching rules, and logical operator usage rules. The search expression syntax specifications refer to the character combination format, field identifier writing, and statement structure requirements that must be followed when constructing the search expression. Field matching rules refer to the matching modes (such as exact matching, fuzzy matching, and inclusion matching) and field calling formats corresponding to different search fields (such as patent invention name, abstract, claims, and applicant). Logical operator usage rules refer to the symbol representation, priority order, and nesting restrictions of logical operators such as "AND," "OR," and "NOT." The parsed search rules are then organized by category to form a structured search rule dataset, providing a clear data foundation for subsequent model processing. Before calling the third model, the natural language retrieval request data, the final keyword set, and the organized retrieval rule dataset are integrated and processed according to the input format required by the third model. During the integration process, the natural language retrieval request data is semantically labeled to indicate the core retrieval intent (e.g., "search for a certain type of technology patent" or "filter patents applied for by a specific institution"); each keyword in the final keyword set is labeled with its vocabulary type (e.g., technical field keywords, institution name keywords, technical feature keywords); and the retrieval rule dataset is hierarchically divided to distinguish between basic grammar rules, field-specific rules, and logical operation rules. After integration, a model call request is initiated through the third model's dedicated calling interface. In addition to carrying the three types of integrated data, the request also needs to configure the model output format parameters (i.e., "patent search formula") and precision control parameters. After receiving the call request, the third model first activates the retrieval rule transfer learning module. This module reads various rules from the retrieval rule dataset and, through a pre-trained rule transformation algorithm, converts the character format requirements and field identification rules in the retrieval syntax specification into vector features that the model can recognize. It also converts the matching patterns and calling formats of different fields in the field matching rules into corresponding vector weights, and transforms the symbol representations, priorities, and nesting restrictions in the logical operator usage rules into vector relation matrices. Through vector transformation, the retrieval rules are converted from textual descriptions into data that the model can compute, providing data support for the third model to adapt to the retrieval syntax of the selected query channel.After completing the retrieval rule vector transformation, the third model activates the core module for generating the retrieval expression. This module first combines the semantic tags of the natural language retrieval demand data to rank the keywords in the final keyword set by importance, identifying keywords with high relevance to the core retrieval intent as core keywords and those with lower relevance as auxiliary keywords. Then, based on the retrieval rule vector characteristics, it matches the corresponding retrieval fields for the core keywords (e.g., technical field keywords match the "invention name" or "abstract" field, and organization name keywords match the "applicant" field), and determines the matching pattern for each keyword according to field matching rules. Next, based on the logical relationship descriptions in the natural language retrieval demand data (e.g., "contains both a technology and an organization," "contains a technology or a feature"), and combined with the logical operator vector relationship matrix, it configures corresponding logical operators between different keywords, while adhering to logical operator priority and nesting rules, thus constructing a preliminary retrieval expression structure. After the preliminary retrieval expression structure is formed, the third model activates the retrieval expression verification module. This module verifies the syntactic correctness, field matching correctness, and the rationality of logical operator usage of the preliminary retrieval expression based on the retrieval rule vector characteristics. If syntax errors (such as incorrect field identifier format), improper field matching (such as matching an organization name keyword with the "Technology Field" field), or violations of logical operator usage (such as failure to nest according to priority) are found, the corresponding parts of the search expression will be automatically adjusted until all validation items meet the requirements of the search rules. After successful validation, the third model outputs a patent search expression that conforms to the specifications of the selected query channel. The patent search expression is then returned to the data processing end via an API call and stored in a dedicated search expression database, providing directly usable search instructions for subsequent patent search operations.

[0053] Step S107: Execute the patent search query and format the search results, then return the patent search query and the formatted search results to the user.

[0054] Specifically, before executing the patent search query, the advanced search interface information corresponding to the selected query channel is extracted from the channel information table. This advanced search interface information includes the interface request address, request method, request header parameters, request body format, and response data format. Based on the extracted advanced search interface information, a search request is constructed: Pre-defined verification information (such as authorization tokens or keys) is entered into the request header to ensure the request's legitimacy; the patent search query is encapsulated in the request body according to the interface's required format. If the interface has encoding requirements for the search query (such as URL encoding or Base64 encoding), the patent search query is encoded accordingly before being entered into the request body; a request timeout and retry mechanism are also set to prevent search operation failure due to network fluctuations or interface response delays. After completing the search request construction, the request is sent to the advanced search interface of the selected query channel, and the interface returns the search response data. Upon receiving the search response data, the system first parses the data to determine if it conforms to the interface's preset response format requirements. If the format is abnormal (e.g., missing data, incorrect fields), a retry mechanism is triggered to resend the search request. If the format is normal, the system extracts the original search results contained in the response data. These original search results typically include the patent name, application number, applicant, publication date, abstract, full text of claims, legal status, and family patent information for each patent. These original search results are then temporarily stored in a temporary results database. When formatting the original search results, they are first initially categorized according to preset result classification dimensions. These dimensions may include technical field category, application time range, and applicant type. Specific classification dimensions can be configured based on the enterprise's business needs, obtained from the channel information table or search rule table. After classification, key information is extracted and structured for each search result: Core information such as patent name, application number, applicant, publication date, core abstract content, core claims (usually independent claims and key dependent claims), and legal status are extracted from the raw data, removing redundant formatting symbols, repetitive descriptions, and irrelevant fields. The extracted core information is then filled into a pre-defined structured template containing fixed information fields (such as "Patent Name:", "Application Number:", "Core Technology Abstract:", etc.) to ensure a consistent and clear presentation of each search result. After formatting, the formatted search results are integrated with the patent search query to form the final result package. The result package clearly distinguishes between the patent search query and the formatted search results. The patent search query is presented in plain text for easy viewing or copying and adjustment by users; the formatted search results are presented in list or paginated format, with each result displaying core information according to the structured template. A sorting function is also provided (e.g., sorting by relevance, publication date, first letter of applicant's name, etc.), allowing users to choose the sorting method according to their needs.When returning results to the user, the result return packet is sent through a preset user interface or a result push interface. If a user interface is used, the interface must have clear area divisions to display the patent search results in both the standard and formatted formats, and provide a result export function (supporting export to document format, table format, etc.). If a result push interface is used, the result return packet must be packaged according to the format required by the interface to ensure that the user's system can correctly parse and display the relevant content. During the return process, the result return time, return method, and user reception status must be recorded to form an operation log stored in the log database for subsequent tracking of the return of search results.

[0055] In some alternative implementations, the first model, the second model, and the third model share the enterprise data knowledge graph.

[0056] Specifically, the enterprise data knowledge graph is a structured knowledge storage system built upon previously acquired enterprise data. Its core content covers the enterprise's internal organizational structure, classification of its proprietary technical fields, historical search terminology association records, and information on collaborations / competitions. The internal organizational structure clearly defines the hierarchical structure and functional divisions of various departments and project teams, such as the technical R&D groups under the R&D department and the patent management department within the intellectual property department. The classification of proprietary technical fields is based on the enterprise's business direction, dividing technical branches and including key R&D directions and related derivative technologies. The historical search terminology association records the terms used in past patent searches, their synonyms, and commonly used extended terms. The information on collaborations / competitions records the full names, abbreviations, and related business areas of external organizations that have cooperative or competitive relationships with the enterprise, providing knowledge support for each model that aligns with the enterprise's actual business scenarios. The first model extracts initial keywords by calling the enterprise data knowledge graph. The specific operation process is as follows: After the first model performs preliminary analysis of the natural language retrieval request data and generates candidate keywords to be screened, it initiates a keyword verification request through a pre-set knowledge graph API. The request carries the candidate keywords and the type identifier of the keywords, such as the organization name identifier or the technical term identifier. After receiving the request, the enterprise data knowledge graph matches the corresponding knowledge module according to the type identifier: If the candidate keyword is marked with an organization name identifier, it matches the internal organizational structure relationship of the enterprise and the association information of the enterprise's cooperative / competitive institutions to verify whether the keyword is the standardized name of the enterprise's internal institutions or the commonly used name of cooperative / competitive institutions. If there are abbreviations or colloquial names, it associates the corresponding standardized full names; if the candidate keyword is marked with a technical term identifier, it matches the enterprise's exclusive technical field category and the enterprise's historical search term association records to determine whether the term belongs to the enterprise's commonly used technical expressions and whether there are simplified terms or technical codes agreed upon by the enterprise internally. The knowledge graph returns the verification results to the first model, including the standardized expressions of candidate keywords, their respective enterprise knowledge categories, and related information. The first model then modifies the candidate keywords based on the verification results, eliminating words irrelevant to the enterprise's business, supplementing standardized expressions, and ultimately generating initial keywords that conform to the enterprise's knowledge system. When generating the final keyword set, the second model calls the enterprise data knowledge graph. The specific operation process is as follows: After the second model completes the initial screening of target channel terminology and target custom terminology, it initiates a term completion request through the knowledge graph's API call. The request carries the filtered valid terms, initial keywords, and the core semantics of the natural language retrieval requirement data.After receiving a request, the enterprise data knowledge graph first locates the enterprise's technical branches corresponding to valid extended terms based on the enterprise's specific technical fields, clarifying the level of the extended term within the enterprise's technical system, such as core technology, auxiliary technology, and derivative technology. Then, combining the enterprise's historical search term association records, it extracts commonly used extended terms related to the valid extended terms, supplementing the enterprise's internal terminology relationships, such as synonyms and related technical directions commonly used in historical searches for a particular technical term. Simultaneously, it considers the enterprise's internal organizational structure; if the extended term involves an organization name, it supplements the corresponding subordinate departments, related project teams, and other relevant names. The knowledge graph returns the completed extended terms and hierarchical association information to the second model. The second model integrates these completed terms with the original valid extended terms and initial keywords, sorts them according to the enterprise's technical logic and organizational relationships, removes duplicate content, and forms a final keyword set covering the enterprise's business characteristics. When the third model generates patent search queries, it invokes the enterprise data knowledge graph. The specific operation process is as follows: Before the third model obtains the search rules for the selected query channel and prepares to match search fields and logical relationships for the final keyword set, it initiates a search adaptation request through the knowledge graph's API. The request carries the final keyword set, the list of search fields for the selected query channel, and the enterprise's business intent from the natural language search requirement data, such as "searching for patents related to a certain R&D project of the enterprise" or "screening patents applied for by the enterprise's partner institutions." After receiving the request, the enterprise data knowledge graph determines the priority of each keyword in the enterprise's business based on the enterprise's specific technical field classification and internal organizational structure. For example, technical keywords related to the enterprise's core R&D direction have higher priority than auxiliary technical keywords, and organizational keywords corresponding to the enterprise's core departments have higher priority than ordinary department keywords. At the same time, it combines the enterprise's historical search term association records to extract past search query configuration experience for similar business intents, such as commonly used search field combinations and logical operator usage habits. The knowledge graph returns the keyword priority ranking results and retrieval configuration reference experience to the third model. Based on these results and the retrieval rules of the selected query channel, the third model assigns appropriate retrieval fields to each keyword and configures logical relationships according to priority. This ensures that the generated patent search query not only conforms to channel specifications but also fits the company's business needs and historical search habits, thereby improving the adaptability of the search query to the company's actual needs.

[0057] In some optional implementations, the second model supports user-defined extended term filtering rules, which include technical field priority, relevance to organization name, and term timeliness.

[0058] Specifically, in the implementation of the second model that supports user-defined extended term filtering rules, these rules are personalized sets of conditions set by the user based on their search needs. These rules primarily include three categories: technical field priority, institution name relevance, and terminology timeliness. Technical field priority rules define the filtering weights for extended terms in different technical fields, allowing users to explicitly retain or exclude extended terms from a specific technical field based on their search objectives. Institution name relevance rules limit the degree of association between institution-related extended terms and the target institution, allowing users to specify the retention of only directly related, indirectly related, or excluded extended terms from specific institutions. Terminology timeliness rules filter extended terms that fall within a specific time range, allowing users to specify the retention of recently appeared, frequently used within a specific time period, or the exclusion of outdated extended terms. These rules need to be entered through a pre-defined interactive interface and stored in the rule configuration database for use by the second model. Before calling the user-defined extended term filtering rules, the second model must first extract the complete filtering rules set by the current user from the rule configuration database via the rule call interface. During the extraction process, the consistency between the user's identity identifier and the rule's identifier must be verified to ensure that the rules obtained are those configured by the current user for this search requirement. After extraction, the filtering rules are formatted by converting user-entered natural language descriptions or selections into rule parameters recognizable by the second model. For example, "prioritize retaining extended terms in the remote sensing field" is converted to "Technology field: remote sensing, weight: high," and "only retain commonly used terms from the last five years" is converted to "Term validity: last five years, filtering method: retain," ensuring that the rule parameters are compatible with the rule parsing logic of the second model. When the second model filters extended terms based on the technology field priority rule, it first extracts all technology field-related extended terms from the target channel thesaurus and the target custom thesaurus. Then, it assigns a weight to each technology field-related extended term based on the technology field weight in the rule parameters. After assignment, the terms are sorted from high to low weight, retaining extended terms with weights reaching the user-defined threshold and removing those with weights below the threshold. For example, if the user sets "geometry has the highest weight, engineering surveying has a medium weight, and other fields have low weight," then geometry extended terms are prioritized, followed by engineering surveying extended terms, and other extended terms are removed. If an extended term involves multiple technology fields, the one with the highest weight is used. When filtering extended terms based on the association rules of organization names, the association degree requirements and target organization range set by the user in the rule parameters are first parsed. Then, all organization-type extended terms are extracted from the extended terms. By comparing the organization association information in the enterprise's internal organization name extended term list and the channel term library, the association type between each organization-type extended term and the target organization is determined.If the user sets "only retain extended terms of directly related organizations," then only extended terms of organizations directly related to the target organization (those with affiliation or cooperation) will be retained. If the user sets "exclude extended terms of a competing organization," then all extended terms related to that competing organization will be removed, ensuring that the retained extended terms of organizations conform to the user's defined scope of association. When filtering extended terms based on terminology timeliness rules, the timeliness information such as the first appearance time and recent usage frequency of each term's extended term is first extracted from the channel thesaurus and the enterprise's internal technical field extended term list. Then, combined with the time range requirements in the rule parameters, the timeliness of each term's extended term is determined. If the user sets "retain commonly used terms from the last three years," then extended terms whose usage frequency in the last three years meets the set standard will be filtered out. If the user sets "exclude outdated terms from five years ago," then extended terms whose first appearance was more than five years ago and have no recent usage records will be removed. After completing the filtering of the three types of rules, the second model integrates the retained extended terms with the initial keywords to form a final keyword set that meets the user's customized needs, ensuring that the final keyword set covers both core search needs and aligns with the user's personalized filtering preferences.

[0059] In some optional implementations, after obtaining the retrieval rules for the selected query channel by calling the query interface, and generating the patent search formula by calling the third model in combination with natural language retrieval demand data, the final keyword set, and the retrieval rules, the method further includes:

[0060] In step b1, the third model performs syntax and logic checks through the retrieval validity verification module. The syntax check matches the retrieval syntax specification of the corresponding query channel, and the logic check detects the reasonableness of the nesting of logical operators in the retrieval expression.

[0061] Furthermore, the built-in retrieval validity verification module of the third model is activated. First, it extracts the retrieval syntax specifications and logical operator usage rules from the previously acquired query rules of the corresponding query channels, storing these as the verification basis in the module's verification rule base. During syntax verification, the retrieval validity verification module breaks down the generated patent retrieval expression into basic units such as field identifiers, keywords, logical operators, and delimiters according to the character sequence. It then compares each basic unit with the retrieval syntax specifications in the verification rule base: checking whether the field identifiers conform to the channel's specified format (e.g., whether they have specific prefixes or suffixes), whether the keywords contain special characters prohibited by the channel, and whether the delimiters use symbols specified by the channel, ensuring that each basic unit meets the syntax requirements. Simultaneously, it checks whether the overall structure of the retrieval expression is complete, and whether there are any issues such as missing field identifiers, unencapsulated keywords, or misaligned syntax units. If any item does not conform to the syntax specifications, it is marked as a syntax verification failure, and the specific error type and location are recorded. During logical validation, the retrieval validity verification module first identifies all logical operators (such as "AND", "OR", and "NOT") in the patent retrieval query, constructs a nested relationship tree of logical operators, and clarifies the hierarchy and scope of each logical operator. Then, based on the logical operator usage rules in the validation rule base, it checks the rationality of the nesting relationships: checking for situations where the nesting level of logical operators exceeds channel restrictions, whether the "NOT" operator is used alone or incorrectly nested, whether there are logical conflicts caused by different priority logical operators not being sorted according to the rules, and whether the keywords or field identifiers associated with the logical operators are missing. For example, if channel rules stipulate that the "NOT" operator cannot be directly nested under the "OR" operator, the module will check for such illegal nesting in the retrieval query; if an "AND" operator is only associated with a single keyword, it is determined that the logical association is incomplete. After completing the logical checks, if any logical problem exists, it is marked as a logical validation failure, and the specific content and location of the logical error are recorded.

[0062] Step b2: When the verification passes, the patent search query will be output.

[0063] Furthermore, after the retrieval validity verification module completes the syntax and logic verification, it generates a verification result report. If both the syntax and logic verification items in the report are marked as "passed," the patent retrieval formula is determined to meet the retrieval requirements of the corresponding query channel. At this time, the third model receives the verification result report and initiates the retrieval formula output process: first, the patent retrieval formula is packaged according to a preset format (such as plain text format or directly copyable code format) to ensure that the packaged retrieval formula can be directly used to call the advanced retrieval interface of the query channel; then, the packaged patent retrieval formula is transmitted to the data storage terminal and stored in the dedicated patent retrieval formula database, while recording the retrieval formula generation time, the corresponding query channel identifier, the verification pass time, and other related information; finally, through the output interface of the third model, the patent retrieval formula is pushed to the module that performs the subsequent retrieval operation, providing a compliant retrieval instruction for executing the patent retrieval formula in step S107.

[0064] Step b3: If the verification fails, readjust the keyword combination and logical relationship of the patent search query until the verification passes.

[0065] Furthermore, if the verification result report generated by the retrieval validity verification module contains markers indicating that syntax or logic verification failed, the third model, upon receiving the report, first analyzes the error type, error location, and error cause recorded in the report to construct the basis for the retrieval adjustment scheme. For syntax errors, the third model corrects the basic units of the error location in the patent retrieval expression according to the retrieval syntax specifications of the corresponding query channel: if the field identifier format is incorrect, the field identifier is regenerated according to the specified format and the original error identifier is replaced; if the keyword contains prohibited special characters, the special characters are removed or escaped according to the channel rules; if the delimiter is incorrect, it is replaced with the delimiter specified by the channel; if the overall structure is missing, the missing syntax units are supplemented (such as completing unencapsulated keywords or adding missing field identifiers). To address logical errors, the third model adjusts the logical relationships and keyword combinations of the patent search query based on the rules for using logical operators and the core semantics of the natural language retrieval data. If the nesting level of logical operators exceeds the limit, the excessive nesting structure is broken down into multiple sets of logical relationships that conform to the level restrictions, while ensuring that the decomposed logical relationships do not deviate from the user's search intent. If the "NOT" operator is used in violation of regulations, the associated objects of the "NOT" operator are redesigned, or replaced with logical combinations that conform to the rules (such as replacing the non-compliant nested "NOT" operator with combinations of "AND" and "OR" operators). If the logical association is incomplete, missing keywords or field identifiers are added to ensure that each logical operator has a complete associated object. If there is a conflict in logical priority, the order of logical operators is adjusted according to the rules, or priority identifiers (such as parentheses) are added to clarify the execution order of each logical relationship. After completing the initial adjustments, the third model retransmits the adjusted patent search query to the search query validity verification module, and restarts syntax and logical verification. If the verification still fails, repeat the above process of parsing errors and adjusting the search query until the search query validity verification module determines that both syntax and logic verification have passed. Then, execute the patent search query output process in step b2 to ensure that the final output patent search query fully meets the search requirements of the corresponding query channel.

[0066] In some optional implementations, the method further includes: controlling the first model, the second model, and the third model to output processing logs, the processing logs including model call times, input parameters, intermediate results, and output results, and storing the processing logs in association with the generated patent search formulas and search results.

[0067] Specifically, the processing log is a structured data file that records key information about the operation of each model, including four core categories: model call time, input parameters, intermediate results, and output results. Model call time refers to the specific time the model call request is initiated; input parameters refer to various types of data passed to the model, such as the natural language retrieval requirement data for the first model, the expanded word data for the second model, and the retrieval rule data for the third model; intermediate results refer to transitional data generated during model operation, such as candidate keywords for the first model, similarity calculation results for the second model, and the preliminary search query structure for the third model; output results refer to the core data finally generated by the model, such as the initial keywords for the first model, the final keyword set for the second model, and the patent search query for the third model. When controlling the output processing log of the first model, the logging function is activated simultaneously with initiating the first model call request. A unified timestamp format is used when recording the model call time to ensure the accuracy and consistency of the time information. When collecting input parameters, the natural language retrieval requirement data passed to the first model is recorded completely, and the data source and format are labeled. During the first model's operation, intermediate results such as candidate keywords and semantic decomposition results generated by the model are captured in real time and recorded sequentially according to the model's operation stages. Each stage's intermediate results are associated with a corresponding time node and processing step identifier. After the first model generates initial keywords, the complete output content is recorded, including the initial keyword list and keyword type annotations (such as technical terms and organization names). After all information collection is complete, the content is integrated according to a preset log template to generate a processing log specific to the first model. The log file name includes the model identifier and call timestamp for easy subsequent identification and retrieval. The operation flow for controlling the second model's output processing log is consistent with the first model, and log recording is started synchronously when the second model is called. When recording input parameters, the incoming natural language retrieval requirement data, initial keywords, target channel thesaurus extended words, and target custom thesaurus extended words are fully collected, while also annotating the transmission order and data volume information of various parameters. When capturing intermediate results, the focus is on recording the relevance values ​​from the semantic similarity calculation module, the scene element extraction results from the surveying terminology context understanding module, and the retention and removal records during the extended word selection process. Each intermediate result is accompanied by a description of the model processing logic (such as the basis for relevance threshold judgment and scene adaptability judgment criteria). When recording output results, all words in the final keyword set, word classification results, and integration logic are fully recorded. The above information is integrated according to the log template to generate a second model processing log containing model identifiers and call timestamps. When controlling the third model output processing log, in addition to recording the usual call time, input parameters, intermediate results, and output results, additional information related to the retrieval rules is recorded. In the input parameter recording stage, in addition to collecting natural language retrieval requirement data, the final keyword set, and retrieval rules, the source channel and version information of the retrieval rules are marked.In the intermediate result recording stage, the focus is on capturing the vector transformation results of the retrieval rule transfer learning module, the keyword priority ranking results of the retrieval expression generation core module, the preliminary retrieval expression structure, and error detection records from the validation module. In the output result recording stage, the final generated patent retrieval expression, retrieval expression syntax, and logic validation results are fully recorded (e.g., validation pass indicators, error correction records). After integrating information according to the template, a third model processing log with a model identifier and call timestamp is generated. When storing the processing log with the generated patent retrieval expressions and search results, a unified association identifier is first constructed. This identifier is a unique string containing information such as the retrieval task number, user identifier, and query channel identifier, ensuring that the association identifier for each retrieval task is unique. This association identifier is added to the processing logs of the first, second, and third models, and the same association identifier is also added to the generated patent retrieval expressions and formatted search results. A dedicated association storage database is established on the data storage side, with an association identifier index field set up in the database. Processing logs, patent retrieval expressions, and search results with the same association identifier are categorized and stored according to the index field. During storage, corresponding storage directories and file formats are set for various types of data. Processing logs are stored in a readable and writable text format, patent search queries are stored in a dual format of plain text and callable code, and search results are stored in a structured table format. Simultaneously, a data association mapping table is established in the database to record information such as the data storage path, generation time, and data status (e.g., validity, update) corresponding to the association identifier. This facilitates quick querying of all processing logs, patent search queries, and search results corresponding to a specific search task using the association identifier, achieving full-chain traceability of the search process and results.

[0068] The patent search query generation method based on a general large model provided in this embodiment firstly establishes a standardized and customized basic data support system for the subsequent patent search process by acquiring enterprise data and configuring channel information tables and search rule tables for each search channel, as well as extended thesaurus of internal organizational names and technical fields. The channel information tables for each search channel clearly define key information such as calling parameters and verification methods for different channels, avoiding call failures or parameter errors caused by inconsistent channel information. The search rule tables standardize the search query syntax and logical requirements for each channel in advance, providing a basis for generating search queries that conform to channel specifications. The enterprise-specific thesaurus incorporates unique organizational names and technical field classifications, making the search process more aligned with the enterprise's actual business scenarios. Secondly, by receiving natural language search request data and selected query channels input by users, the method directly connects with the user's original search intent, breaking the dependence of traditional searches on professional operations. Users don't need to learn complex search condition settings or search query writing rules; they only need to describe their search needs in natural language, similar to everyday conversation, and choose familiar or frequently used query channels. This significantly lowers the barrier to entry for patent searches, allowing users with different knowledge backgrounds to quickly initiate search requests and improving the convenience and user experience of the search operation. Then, the first model extracts initial keywords from the natural language search request data, achieving accurate parsing and core information extraction of the user's natural language needs. Leveraging its understanding of the semantics of the patent field, the first model filters out key content related to patent searches, such as technical terms, institution names, and technical directions, from the user's potentially redundant natural language descriptions. This avoids the omission of core information due to subjective judgment bias or insufficient professional knowledge during manual keyword extraction, ensuring that the initial keywords accurately reflect the user's core search needs. Subsequently, by expanding the selected query channels and initial keywords, target channel thesaurus expansion words and target custom thesaurus expansion words are obtained, enriching the coverage of search keywords and improving the comprehensiveness of the search. Based on the channel-specific thesaurus expanded with selected query channels, industry-wide synonyms, hypernyms, and hyponyms accumulated by those channels can be incorporated to compensate for the insufficient coverage of diverse technical expressions by single keywords. Custom-defined thesaurus expanded with internal enterprise terms can supplement the company's proprietary terminology and related vocabulary, ensuring the keyword system encompasses both industry commonalities and company characteristics, effectively reducing the omission of relevant patents due to differences in terminology. Furthermore, by calling a second model based on natural language retrieval demand data, initial keywords, target channel thesaurus expanded terms, and target custom-defined thesaurus expanded terms, a final keyword set is generated, enabling precise filtering and optimization of expanded terms.The second model combines the context of the user's natural language needs to determine the semantic relevance of each expanded term to the initial keywords, eliminating irrelevant or weakly related expanded terms to avoid redundant search scope caused by invalid expanded terms. Simultaneously, it systematically integrates effective expanded terms to form a logically clear and precisely covered final keyword set, ensuring that the subsequently generated search queries focus on the user's core needs and improve the relevance of search results. Next, by calling the query interface based on the selected query channel to obtain the corresponding query rules, and calling the third model to combine the natural language search requirement data, the final keyword set, and the search rules to generate patent search queries, ensures that the generated search queries conform to the technical specifications of the specific channel, improving the effectiveness and adaptability of the search queries. The query interface can obtain the latest search rules from each channel in real time, avoiding search query failures due to untimely rule updates; the third model can deeply integrate user needs, keywords, and channel rules, automatically constructing grammatically correct and logically rigorous search queries without requiring manual formatting adjustments or addition of logical operators, significantly improving the efficiency and accuracy of search query generation. Finally, by executing the patent search query and formatting the search results, the system returns the patent search query and the formatted search results to the user, providing a complete and clear search output and improving the usability of the search results. Executing the search query directly connects to the query channel to obtain the original search data, ensuring the timeliness and completeness of the results; formatting organizes the original data in a structured way, highlighting key information such as patent names, abstracts, and core clauses, facilitating quick browsing and filtering for users; simultaneously, the generated search query is returned, allowing users to further adjust and optimize it according to their actual needs, achieving dual transparency in both the search results and the search process, enhancing user trust in the search results and ease of use. By implementing this invention, the system solves the problem that related technologies cannot meet the comprehensive needs of low-threshold operation, high-precision matching, customized adaptation, and dynamic thesaurus updates in patent retrieval.

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

Claims

1. A patent retrieval formula generation method based on a general large model, characterized in that, The method includes: Acquire enterprise data, and configure channel information tables and search rule tables for each search channel based on the enterprise data, as well as extended term tables for internal organizational names and extended term tables for technical fields; Receive natural language search request data and selected query channel input by the user; The first model is invoked to extract the natural language retrieval request data to obtain initial keywords; The selected query channel and the initial keywords are expanded to obtain target channel terminology and target custom terminology. The second model is invoked to generate the final keyword set based on the natural language retrieval demand data, the initial keyword target channel thesaurus extension words, and the target custom thesaurus extension words; Based on the selected query channel, the query interface is called to obtain the retrieval rules of the corresponding query channel. The third model is then called to combine the natural language retrieval requirement data, the final keyword set, and the retrieval rules to generate a patent retrieval formula. The patent search query is executed and the search results are formatted. The patent search query and the formatted search results are then returned to the user.

2. The method according to claim 1, characterized in that, The channel information table includes channel name, channel code, channel type, calling method, request address, verification information, and calling parameters. The channel type is divided into advanced search type and thesaurus type. The calling method includes Hypertext Transfer Protocol calling method and WebSocket protocol calling method. The search rule table contains the search syntax specifications, field matching rules, and logical operator usage rules for each search channel.

3. The method according to claim 2, characterized in that, The first model is a general-purpose large model that has been pre-trained and optimized using patent domain corpus.

4. The method according to claim 3, characterized in that, The expansion of the selected query channel and the initial keywords to obtain target channel terminology expansion words and target custom terminology expansion words includes: The query interface is called through the code node to query the channel information table, and it is determined whether the query channel is configured with a thesaurus query interface. If the query channel is configured with the thesaurus query interface, the thesaurus query interface is called and the initial keyword is input to obtain the organization extension words and technology extension words corresponding to the initial keyword in the channel thesaurus. The organization extension words and the technology extension words are used as the target channel thesaurus extension words. The query interface is called through the code node to check whether the enterprise has configured a custom thesaurus query interface. If the enterprise has configured the custom thesaurus query interface, the custom thesaurus query interface is called and the initial keyword is input. The organization name extension words corresponding to the initial keyword are obtained from the enterprise's internal organization name extension word table, and the technology extension words corresponding to the initial keyword are obtained from the enterprise's internal technology field extension word table. The organization name extension words and the technology field extension words are used as the target custom thesaurus extension words. The target channel terminology extension words and the target custom terminology extension words are deduplicated to obtain the target channel terminology extension words and the target custom terminology extension words.

5. The method according to claim 4, characterized in that, The second model is a large-parameter general-purpose model with a parameter scale of 10 billion. The second model has a built-in semantic similarity calculation module and a surveying and mapping terminology context understanding module. The semantic similarity calculation module uses the cosine similarity algorithm to calculate the relevance of the target channel terminology extension words and the target custom terminology extension words to the initial keywords. The surveying and mapping terminology context understanding module combines the scenario description in the natural language retrieval requirement data to determine the applicability of the target channel terminology extension words and the target custom terminology extension words in the surveying and mapping archive retrieval scenario.

6. The method according to claim 5, characterized in that, The third model is a large-parameter general model with a parameter scale of 20 billion. The third model adapts to the retrieval syntax of different query channels through the retrieval rule transfer learning module. The retrieval rule transfer learning module transforms the retrieval syntax specifications, field matching rules and logical operator usage rules of each query channel into vector representations.

7. The method according to claim 6, characterized in that, The first model, the second model, and the third model share the enterprise data knowledge graph.

8. The method according to claim 7, characterized in that, The second model supports user-defined extended term filtering rules, which include technical field priority, relevance to organization name, and term timeliness.

9. The method according to claim 8, characterized in that, After obtaining the retrieval rules for the selected retrieval channel by calling the query interface, and generating the patent search formula by calling the third model in conjunction with the natural language retrieval requirement data, the final keyword set, and the retrieval rules, the method further includes: The third model performs syntax and logic checks through a retrieval validity verification module. The syntax check matches the retrieval syntax specification of the corresponding query channel, and the logic check detects the reasonableness of the nesting of logical operators in the retrieval expression. If the verification passes, the patent search query will be output. If the verification fails, readjust the keyword combination and logical relationship of the patent search query until the verification passes.

10. The method according to claim 9, characterized in that, The method further includes: The system controls the output processing logs of the first model, the second model, and the third model. The processing logs include model call time, input parameters, intermediate results, and output results. The processing logs are stored in association with the generated patent search formula and search results.

Images