House search method, device, storage medium and program product

Abstract

This application provides a property search method, device, storage medium, and program product. In this solution, inference-type slot templates and non-inference-type slot templates are dynamically generated based on the inference depth type of keywords contained in the user's property search information. These two sets of slot templates with different inference depths correspond to a tightly coupled, differentiated processing flow: a large model is filled with inference-type keywords to obtain inference-type structured parameters, while a small model is filled with non-inference-type keywords in parallel to obtain non-inference-type structured parameters. The resulting target structured intent parameters are then fused and transformed into an executable, high-precision structured property search statement. This allows for property search using inference-type fields as the main query conditions and non-inference-type fields as filter query conditions, resulting in a target property set. This improves the accuracy and efficiency of property search while enhancing the accuracy of intent recognition.

Description

Technical Field

[0001] This application relates to the field of computer processing technology, and in particular to a method, device, storage medium and program product for searching housing listings. Background Technology

[0002] With the development of mobile internet, online rental platforms have become a primary channel for users to find housing. Typically, users can manually input their housing needs through text (e.g., in the search box) or voice on these platforms. The platform can then analyze this information to extract key requirements and search for suitable properties based on these requirements. Specifically, the platform can use a model to analyze the user's input and extract key information. This extraction process involves building a template and filling in the corresponding slots to obtain the key requirements. Finally, this key information is mapped to a housing database to search for properties, resulting in the search results.

[0003] However, the above method has certain limitations, as follows: First, online rental platforms can use either large models with numerous parameters or small models with few parameters. Large models possess powerful reasoning capabilities and can accurately understand the semantics of complex housing demand information (e.g., colloquial, complex, and / or dialect-based housing demand information). However, they are slow and costly when processing simple rule-based information. On the other hand, while small models have lower processing costs, they are insufficient for handling complex housing demand information and cannot understand complex semantics.

[0004] Second, when the model extracts key requirement information, it fills the slots in the template based on the key information to obtain the key requirement information. The slot filling method is singular, making it difficult to balance efficiency and accuracy.

[0005] Third, when mapping key demand information to the housing database for housing search, relying on a single key demand information for housing search is a crude retrieval strategy, which may result in housing retrieval results having a low relevance to the user's actual needs.

[0006] There is currently no good solution to the above problems. Summary of the Invention

[0007] Compared to traditional solutions that use models to generate single keyword templates and assign a single template to a single subsequent processing flow, this application recognizes that keywords in housing demand information are not homogeneous, and their 'contribution' and 'contribution method' to the final intent are different. Therefore, this application first uses a multi-source weighted algorithm to evaluate and classify the importance of keywords. This classification directly determines and drives the generation and sorting of subsequent 'reasoning slot templates' and 'non-reasoning slot templates'. Different downstream processing flows are designed for the two sets of slot templates with different reasoning depths, achieving a tight coupling between front-end classification based on the inherent characteristics of key information and back-end differentiated processing flows. This solves the problem of how to efficiently and accurately process information fragments with different logical depths (such as direct factual statements and implicit needs requiring reasoning) mixed in users' colloquial needs under zero-sample or small-sample conditions, and collaboratively transform them into an executable, high-precision structured query. This improves the accuracy of housing search and search efficiency while enhancing the accuracy of intent recognition.

[0008] This application provides a housing search method, comprising: acquiring housing demand information input by a user in natural language; inputting the housing demand information into a first large language model, generating inference-type slot templates and non-inference-type slot templates adapted to the housing demand information based on the inference depth types of multiple keywords contained in the housing demand information, wherein the inference depth types include inference type and non-inference type; inputting at least one first keyword belonging to the inference type and the inference-type slot template into a second large language model, and using chain thinking and function call methods to complete the slot filling of the inference-type slot template to obtain inference-type structured parameters; inputting at least one second keyword belonging to the non-inference type and the non-inference-type slot template into a lightweight model, and completing the slot filling of the non-inference-type operation template based on preset slot filling rules to obtain non-inference-type structured parameters; fusing the inference-type structured parameters and non-inference-type structured parameters to obtain target structured intent parameters; mapping the target structured intent parameters to a housing search statement, and performing a housing search using the inference-type fields in the housing search statement as the main query conditions and the non-inference-type fields as the filter query conditions to obtain a target housing set.

[0009] This application provides an electronic device, including: a memory and a processor; the memory for storing a computer program; and the processor, coupled to the memory, for executing the computer program to implement the steps in the above method.

[0010] This application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps in the above-described method.

[0011] This application provides a computer program product comprising a computer program / instructions that, when executed by a processor, enable the processor to perform the steps in the above-described method.

[0012] In this embodiment, two sets of slot templates with different inference depths are dynamically generated based on the inherent characteristics (inference depth type) of keywords contained in the user's housing demand information. These templates are inference-type and non-inference-type. A large model fills in inference-type keywords to obtain inference-type structured parameters, while a small model fills in non-inference-type keywords in parallel to obtain non-inference-type structured parameters. This allows the system to achieve millisecond-level response using lightweight rules while leveraging a large model for deep semantic inference, ultimately achieving a synergistic improvement in high accuracy and low latency within the same process. The resulting target structured intent parameters are then transformed into an executable, high-precision structured housing search statement. This statement uses inference-type fields as the main query conditions and non-inference-type fields as filter query conditions to search for housing, resulting in a target housing set. By designing different downstream processing flows for two sets of slot templates with different inference depths, the front-end classification based on the inherent characteristics of key information and the back-end differentiated processing flow are tightly coupled. All key information is collaboratively transformed into an executable, high-precision structured query, which improves the accuracy of property search and search efficiency while enhancing the accuracy of intent recognition. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1a A flowchart illustrating a housing search method provided for an exemplary embodiment of this application; Figure 1b A schematic flowchart illustrating a slot template generation method provided in an exemplary embodiment of this application; Figure 1c A flowchart illustrating another slot template generation method provided for another exemplary embodiment of this application; Figure 2 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Detailed Implementation

[0014] Following the aforementioned background technology, and addressing the technical problems existing in the background technology, this application embodiment dynamically generates two sets of slot templates with different inference depths—inference-type slot templates and non-inference-type slot templates—based on the inherent characteristics (inference depth type) of the keywords contained in the user's housing demand information. A large model is filled with inference-type keywords to obtain inference-type structured parameters, while a small model is filled with non-inference-type keywords in parallel to obtain non-inference-type structured parameters. This allows the system to achieve millisecond-level response using lightweight rules while simultaneously leveraging a large model to complete deep semantic inference, ultimately achieving a synergistic improvement in high accuracy and low latency within the same link. Furthermore, the target structured intent parameters after merging the two are transformed into an executable, high-precision structured housing search statement. This allows for housing searches using inference-type fields in the housing search statement as the main query conditions and non-inference-type fields as filter query conditions, resulting in a target housing set. By designing different downstream processing flows for two sets of slot templates with different inference depths, the front-end classification based on the inherent characteristics of key information and the back-end differentiated processing flow are tightly coupled. All key information is collaboratively transformed into an executable, high-precision structured query, which improves the accuracy of property search and search efficiency while enhancing the accuracy of intent recognition.

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

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

[0017] Additionally, it should be noted that when user interaction operations or triggering operations are involved in the embodiments of this application, these operations include, but are not limited to, various interaction methods such as touch operations, gesture operations, voice operations, head movement operations, and eye movement operations. Touch operations include, but are not limited to, click operations, double-click operations, long-press operations, swipe operations, pinch operations, or mouse hover operations. Swipe operations include, but are not limited to, straight-line swipes and curved-line swipes.

[0018] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0019] Figure 1a This is a flowchart illustrating a housing search method provided as an exemplary embodiment of this application. Figure 1a As shown, the method includes: 101. Obtain housing demand information input by users in natural language format; 102. Input the housing demand information into the first language model. Based on the reasoning depth type of multiple keywords contained in the housing demand information, generate reasoning slot templates and non-reasoning slot templates that are adapted to the housing demand information. The reasoning depth type includes reasoning type and non-reasoning type. 103. Input the first keyword belonging to the reasoning type and the reasoning slot template into the second language model, and use chain thinking and function call to fill the slots of the reasoning slot template to obtain the reasoning structured parameters. 104. Input the second keyword belonging to the non-reasoning type and the non-reasoning slot template into the lightweight model, and fill the slots of the non-reasoning operation template based on the preset slot filling rules to obtain the non-reasoning structured parameters. 105. By fusing reasoning-based structured parameters and non-reasoning-based structured parameters, the target structured intent parameters are obtained; 106. Map the target structured intent parameters to a property search statement, use the inference fields in the property search statement as the main query conditions and the non-inference fields as the filter query conditions to search for properties and obtain the target property set.

[0020] The property search method in this embodiment can be applied to a property listing platform that maintains diverse listings covering different regions, price ranges, environments, and housing types. When a user has a property search requirement, the platform can execute the property search method based on the user's provided requirements, thereby presenting the user with a set of matched target properties for selection. The property listing platform can be implemented as a standalone app, a mini-program dependent on an app, or a web page, etc., and this embodiment does not limit this.

[0021] In this embodiment, when a user needs to search for properties, the user can submit their property search request information to the property platform, which will then search for properties based on that information. See also Figure 1a In step 101, the user's housing demand information, input in natural language, can be obtained. This housing demand information can be a complete sentence in natural language, such as "I need a one-bedroom apartment that is 3 kilometers from my current location, about a 20-minute commute, and allows pets." Alternatively, the housing demand information can also be at least one key information fragment, such as combinations of different forms like "3 kilometers from my current location," "20-minute commute," "allows pets," "easy for pet walking," and "one-bedroom apartment." The housing demand information can be text information, voice information, or any other information type that can express the user's needs; this embodiment does not limit this.

[0022] This embodiment does not limit the method of obtaining housing demand information input by users in natural language. For example, the housing platform provides a housing search interface, which includes an information input box where users can input housing demand information in natural language; or, the housing search interface includes a voice input control, allowing users to input housing demand information in natural language; or, the housing search interface includes multiple keyword controls, each corresponding to a keyword described in natural language, allowing users to combine keywords into their housing demand information by triggering at least one keyword control; or, the housing platform provides a chat interface, allowing users to chat with the platform's customer service and input their housing demand information during the chat. The housing platform has developed a simultaneous interpretation plugin. Users receive voice information and translates it into text in real time. When users input their housing needs in natural language via voice input controls, the plugin converts the voice information into text and stores it along with user information in the cloud or locally. This facilitates the determination of a target housing set based on the housing needs information. Furthermore, after the user selects their preferred housing, they can communicate further with the housing agent or homeowner based on their information, such as creating a communication channel between the user and the agent or homeowner. The specific content of the user information and the triggering method of the triggering controls can be found in the relevant descriptions of the above embodiments, and will not be repeated here.

[0023] Typically, property listing information contains multiple keywords, each corresponding to a key piece of information and belonging to a specific keyword type. The depth of key information carried by different types of keywords varies; some keywords' key information can be directly derived from their literal meaning, while others require further inference. Furthermore, different keywords contribute differently to the user's ultimate intent regarding the property listing information. Contribution represents the importance of a keyword to that intent, which can be determined by a combination of factors such as basic statistics, scenario matching, and personalized preferences. Therefore, the importance of keywords can be evaluated and categorized based on factors such as basic statistics, scenario matching, and personalized preferences. This categorization can drive the generation of different slot templates and the ranking of slots within the same slot template. Basic statistics involve a literal quantification of the frequency and position of keywords in the historical property listing database logs. A score in the range [0,1] is obtained by multiplying the exact / prefix / substring matching degree and positional weights such as title-tag-body text, which is used to quickly amplify the intuitive relevance between keywords and property listing metadata. Scene matching measures the fit between keywords and the scene thesaurus of the current request. The system first identifies the scene using a high-confidence field (e.g., finding a house near a subway station, pet-friendly), then adds or deducts points for keywords according to pre-set weights, making the template ranking closer to the real-time business context. The scene thesaurus is a "keyword set" pre-maintained for each business scene, used to quickly determine whether a keyword belongs to that scene at runtime. Personalized preferences encode users' recent browsing, favorites, and micro-chat behaviors into vectors, calculate the time decay cosine similarity with the keyword vectors, and use a city-wide general distribution as a prior during cold start, outputting a score of [0,1] to ensure that the keyword ranking reflects personal historical interests.

[0024] Based on this, in order to accurately distinguish the types of keywords and lay the foundation for subsequent precise property searches, after obtaining the user's property demand information, see [link to relevant documentation]. Figure 1a Step 102 involves inputting housing demand information into the first large language model. Based on the inference depth type of multiple keywords contained in the housing demand information, inference-type slot templates and non-inference-type slot templates adapted to the housing demand information are generated. Compared with the traditional solution that uses a large model to generate a single keyword slot template, this solution dynamically generates two sets of templates based on the inherent characteristics of the keywords (i.e., inference type / non-inference type), laying the foundation for designing different downstream processing flows based on the two sets of templates.

[0025] Inference depth quantifies the minimum number of intermediate semantic transformations required to convert each keyword in a user's natural language description of their housing needs into its corresponding key information. If the transformation path involves at least one jump from "keyword → literal meaning → intermediate semantics → final key information," then the inference depth is 1, corresponding to the "inference type." If the key information can be obtained directly from the literal meaning or synonyms in one step, then the inference depth is 0, corresponding to the "non-inference type." Inference depth type refers to the category label of the 'external knowledge or computational steps' required to obtain deterministic parameter values ​​that can be directly retrieved from the housing database when performing semantic analysis on the user's natural language description of their housing needs. In other words, inference depth types include: inference type and non-inference type. Inference type indicates that the key information corresponding to a keyword needs to be obtained through inference, not literal meaning; in other words, inference type refers to obtaining the corresponding key information by using an external knowledge base, spatial / temporal algorithms, or logical deduction to perform at least one intermediate semantic transformation on the corresponding keyword. For example, if the inferential keyword is "20 minutes to point A," then the key information (i.e., inferential information) corresponding to this keyword is "the latitude and longitude range of the commuting area (including specific range values)." Another example is "convenient for pet walking," which means "nearby with lawns or parks." Non-inferential keywords, on the other hand, represent keywords whose key information is simply their literal meaning. In other words, non-inferential keywords do not require external knowledge bases, spatial / temporal algorithms, or logical deduction, and do not generate any intermediate semantics. For example, "price 5000 / month" means the key information corresponding to this non-inferential keyword is simply the literal meaning of a house price of 5000 / month; another example is "three-bedroom apartment," which means the key information corresponding to this non-inferential keyword is that the apartment has three bedrooms.

[0026] In addition, a slot template refers to a standardized list of fields dynamically generated by a large model to extract structured parameters from user-input housing demand information; in other words, a slot template is a pre-declared semi-structured query skeleton for completing a housing search. This skeleton consists of a set of slot sequences ordered by business priority. Each slot in the slot template corresponds to at least a field name, data type, and required field flag, which tells the subsequent filling engine what information needs to be extracted, what standard form this information should be converted into, which is prioritized, which is optional, and how it is ultimately mapped one-to-one with the fields in the housing database. The field name refers to the Chinese or English identifier of the database field that can be queried or published. It is used to clarify the specific business dimension corresponding to the subsequent slot filling, such as "subway station name", "budget price", "apartment structure", "house area", "floor", "decoration standard", etc. The data type refers to the storage format constraints of the field in the database to ensure that the filled value conforms to the database storage specifications. The storage format includes, but is not limited to: string type (for text information such as community name and address), integer type (for numerical information such as floor and area), enumeration type (for limited options such as decoration level and orientation), or boolean type (for binary information such as whether there is an elevator or parking space). The required field flag is to use a boolean value (yes / no) or binary bit (1 / 0) to indicate whether the field must be filled, so as to trigger the missing value inquiry or default value completion mechanism when filling the slots, ensuring the integrity of the structured parameters. For example, in the scenario of "searching for houses by subway", "subway station name" is required and "decoration standard" is optional. In this application, slot templates are categorized into inference-type and non-inference-type slot templates based on whether inference depth is required for the information within the slots. Inference-type slot templates are required for those requiring inference depth, while non-inference-type slot templates are not. Essentially, they serve the same goal: transforming natural language into a set of standardized fields, i.e., generating structured parameters. However, they differ in the source of slot content and the filling channels. Specifically, although both inference-type and non-inference-type slot templates belong to the same upper-level concept of "template," they exhibit distinct differences in content source, filling mechanism, and downstream applications. First, inference-type slot templates target keywords with "inference depth = 1." Their slot values ​​cannot be directly stored in the database at once; they must rely on a second language model to perform intermediate semantic transformations using chain-like thinking and function calls. For example, converting "20-minute commute" into isochronous latitude and longitude ranges, or inferring "convenient for pet walking" as "nearby with lawns or parks." This process typically takes hundreds of milliseconds to complete, and the output is a structured parameter with intermediate inference results, which serves as the "main query condition" in subsequent searches, first performing a coarse recall on all housing listings.Non-inference-based slot templates handle keywords with "inference depth = 0". Slot values ​​can be directly mapped using regular expressions, dictionaries, or if-else rules. For example, "Chaoyang District", "8000 yuan", and "three-bedroom apartment" can be directly standardized into fields such as district, price_max, and room_num. Lightweight models can complete the filling in milliseconds, generating structured parameters without intermediate products. Finally, these parameters act as "filtering conditions" to refine the results on top of the coarse recall. Furthermore, inference-based templates allow large models to infer default values, while non-inference-based templates rely on required default values ​​or dictionary default values. The former's template instances are dynamically generated based on user speech and change hourly, while the latter are updated daily or weekly with changes to the business dictionary. In short, inference-based slot templates are responsible for "thinking things through" and producing fields, while non-inference-based slot templates are responsible for "reading the literal meaning" and producing fields. Only after both are combined do they enter the standardized query stage, jointly completing the transition from natural language to executable retrieval.

[0027] Furthermore, the first large language model can be an AI large model. An AI large model refers to a model whose parameters meet the set parameter quantity requirements. This embodiment does not limit the parameter quantity requirements; different definitions are possible in different scenarios and fields. For example, in a housing search scenario, an AI large model can refer to a model with a parameter scale reaching tens of billions, hundreds of billions, or even trillions. However, this definition of the model's parameter quantity is merely an example and does not constitute a limitation on this application. This embodiment also does not limit the type of AI large model, such as a Large Language Model (LLM), PaLM, or LLaMA.

[0028] Furthermore, after obtaining the inference-type slot template and the non-inference-type slot template, slot filling can be performed on the inference-type slot template and the non-inference-type slot template based on multiple key information to obtain the parameters corresponding to the two types of slot templates respectively. In order to improve the slot filling efficiency, models can be used for slot filling. Models usually include small models and large models. Among them, small models are lightweight models, which refer to models with parameter scales usually in the millions to tens of millions or less, and peak values ​​not exceeding hundreds of millions. This parameter range is only an example and does not constitute a limitation on this application. Small models can be, for example, lightweight language models (SLM), DistilBERT, TinyLLaMA, or MobileViT, which are compressed / distilled models that can perform inference on terminal devices or edge devices. Large models can be the AI ​​large models in the above embodiments. For specific definitions, please refer to the relevant descriptions in the above embodiments, which will not be repeated here. In addition, slot filling of inference-type slot templates requires semantic understanding and semantic reasoning, which requires the model filling the inference-type slot template to have strong reasoning ability. Therefore, slot filling of inference-type slot templates is more suitable for large models. On the other hand, slot filling of non-inference-type slot templates can be based on fixed rules, which requires the model filling the non-inference-type slot template to maintain high efficiency and determinism. Therefore, slot filling of non-inference-type slot templates is more suitable for lightweight models.

[0029] Based on the above, in order to further improve the overall filling efficiency of inference-type slot templates and non-inference-type slot templates, slot filling can be performed on inference-type slot templates and non-inference-type slot templates respectively through two parallel links. The two parallel links do not wait for each other, as detailed below: See below for filling the inference slot template. Figure 1aStep 103 involves inputting at least one primary keyword belonging to the reasoning type and the reasoning slot template into the second large language model. Chain-of-Thought (CoT) and function calls are then used to fill the slots in the reasoning slot template, yielding the reasoning structured parameters. Chain-of-Thought refers to the autoregressive process by which the large model generates the mapping relationship between intermediate semantic and numerical units step-by-step before outputting the final slot value. Each step's result is written into the same response, forming a thought chain that can be parsed downstream. An example thought chain is: ① Semantic label (transportation mode = subway) → ② Numerical quantity (radius = 3200 m) → ③ Function parameter package ({center:, radius:}). This thought chain is completed within a single reasoning iteration without adding extra requests, and is used to break down complex requirements into multiple sub-steps, ensuring that the final parameters are computable and interpretable. Function calls refer to the interface action of a large model actively triggering a pre-defined function at the end of the chain-like reasoning process. Specifically: the function is registered in the large model context, with a fixed name and input parameter structure; the large model fills in the input parameters according to the intermediate results generated by the chain-like reasoning process and outputs the call instruction; the system parses the instruction and immediately executes the function, returning the result directly to the corresponding slot field. Therefore, function calls are not Remote Procedure Calls (RPCs), but rather the model generates call statements that conform to pre-defined rules, which are executed locally by the framework to instantly transform semantic inference results into executable parameter values, completing the final assignment of inference slots. Obtaining structured parameters refers to encapsulating the set of key-value mappings—which, after slot filling, has standardized field names and values ​​conforming to the housing database specifications—into a JSON object (or other equivalent structured format) that can be directly consumed by downstream search engines. Each record in this object contains: a field name, with each field name corresponding one-to-one with the query fields in the housing database (e.g., district, price_max, room_type); a field value, which is the final valid value after normalization, deduplication, and unit unification (e.g., "Chaoyang District", "8000", "3 rooms"); and a type tag, i.e., an additional inference / non-inference label, used for subsequent main query and filtering. Therefore, obtaining structured parameters can be understood as completing the final standardization step from natural language to an executable query statement, ensuring that no further cleaning or mapping is needed in the subsequent retrieval stage.

[0030] For filling non-inference slot templates, please refer to [link / reference]. Figure 1aStep 104: Input at least one second keyword belonging to the non-reasoning type and the non-reasoning slot template into the lightweight model. Based on the preset slot filling rules, complete the slot filling of the non-reasoning slot template to obtain non-reasoning structured parameters. The preset slot filling rules refer to a set of deterministic mapping and verification logic pre-compiled and solidified in the rule engine by the housing platform. These rules are used to directly convert non-reasoning keywords into standard field values ​​without model reasoning. The preset slot filling rules include, but are not limited to: synonym unification (e.g., "three-bedroom" ↔ "3 rooms", "8k" ↔ "8000 yuan"); numerical range truncation (e.g., rent > 300,000 → truncate to the 300,000 upper limit, area < 1㎡ → discard); enumeration of preset lists (e.g., the apartment type field only accepts {1 room, 2 rooms, 3 rooms, 4 rooms, 4 rooms or more}), discarding the rest; conflict and mutual exclusion (e.g., ... Simultaneously, both "entire rental" and "shared rental" appear → the earlier location is used; required fields are left blank (e.g., if "rent" is not retrieved → fill with the city's default rent range), meaning all preset slot filling rules exist in the form of if-else statements or lookup tables, supporting hot updates. This ensures that the small model channel completes non-inference-type slot assignment within milliseconds, and the output fields conform as comprehensively as possible to the preset rules of the housing database. Therefore, the lightweight model handles literal matching and explicit information with fast response, while the large model handles inference, processes implicit needs, and has strong semantic understanding capabilities, thus achieving optimal resource allocation and performance optimization.

[0031] In summary, the system can achieve millisecond-level response using lightweight rules, and can also complete deep semantic reasoning with the help of large models, ultimately achieving a synergistic improvement in high accuracy and low latency within the same link.

[0032] Furthermore, after obtaining the inference-based structured parameters and the non-inference-based structured parameters, referring to step 105, the inference-based and non-inference-based structured parameters can be fused, such as by fusing them in a preset order, to obtain the target structured intent parameters. This allows for property searches in the property database based on the target structured parameters. Fusing the output data of the two collaborative models in a preset order forms complete structured intent parameters, ensuring a synergistic improvement in both high accuracy and low latency, thereby enhancing the accuracy and efficiency of property searches.

[0033] Subsequently, to facilitate property searches within the property database, see [link to relevant documentation]. Figure 1aStep 106 involves mapping the target structured intent parameters to a property search statement, enabling property searches within the property database based on this statement. Specifically, the property search statement includes inference fields and non-inference fields. Inference fields are populated with inference-based structured parameters, while non-inference fields are populated with non-inference-based structured parameters. Furthermore, the range of properties corresponding to inference-based structured parameters is relatively broad, while the range of properties corresponding to non-inference-based structured parameters is relatively narrower and encompassed within the range of properties corresponding to inference-based structured parameters. Therefore, a layered search can be performed using the inference fields in the property search statement as the primary query condition and the non-inference fields as the filtering query condition to obtain the target property set. This layered search approach, involving a broad initial screening followed by a narrower, more detailed screening, can improve the accuracy and efficiency of the property search.

[0034] In addition, for the specific implementation of steps 101-106 above, please refer to the relevant description in the following embodiments, which will not be repeated here.

[0035] The technical solutions provided in the above embodiments of this application dynamically generate two sets of slot templates with different inference depths—inference-type slot templates and non-inference-type slot templates—based on the inherent characteristics (inference depth type) of the keywords contained in the user's housing demand information. A large model fills in inference-type keywords to obtain inference-type structured parameters, while a small model fills in non-inference-type keywords in parallel to obtain non-inference-type structured parameters. This allows the system to achieve millisecond-level response using lightweight rules while simultaneously leveraging a large model to complete deep semantic inference, ultimately achieving a synergistic improvement in high accuracy and low latency within the same process. The resulting target structured intent parameters are then transformed into an executable, high-precision structured housing search statement. This statement uses inference-type fields as the main query conditions and non-inference-type fields as filter query conditions to perform a housing search, resulting in a target housing set. By designing different downstream processing flows for two sets of slot templates with different inference depths, the front-end classification based on the inherent characteristics of key information and the back-end differentiated processing flow are tightly coupled. All key information is collaboratively transformed into an executable, high-precision structured query, which improves the accuracy of property search and search efficiency while enhancing the accuracy of intent recognition.

[0036] Following the above embodiment of generating inference-type slot templates and non-inference-type slot templates adapted to housing demand information, in step 102, the housing demand information is input into the first large language model. Based on the inference depth type of multiple keywords contained in the housing demand information, generating inference-type slot templates and non-inference-type slot templates adapted to the housing demand information can be implemented in various ways. Figure 1b A flowchart illustrating an optional implementation of a slot template generation method provided as an exemplary embodiment of this application is shown below. Figure 1b The optional implementation includes: 201. Input the housing demand information into the first language model, and break down the housing demand information into keywords according to the overall intent corresponding to the housing demand information to obtain multiple keywords; 202. Perform attribute analysis on each keyword and determine the reasoning depth type of each keyword based on the attribute analysis results, so as to obtain at least one first keyword belonging to the reasoning type and at least one second keyword belonging to the non-reasoning type; 203. Determine the importance of at least one primary keyword; 204. Sort at least one primary keyword according to its importance to obtain the first ranking result; 205. Based on the first sorting result, generate a reasoning-type slot template; And, 206, determine the importance of at least one secondary keyword; 207. Sort at least one secondary keyword according to its importance to obtain a second ranking result; 208. Based on the second sorting result, generate a non-reasoning slot template.

[0037] In step 201 above, the housing demand information is input into the first language model. Based on the overall intent corresponding to the housing demand information, the housing demand information is split into keywords to obtain multiple keywords. Optional implementation methods include: inputting the housing demand information into the first language model, performing deep intent inference, and outputting attitude labels, attitude-targeted entities, and descriptions of the user's true positive needs; if the attitude is rejection, the entity targeted by rejection is inverted as the final keyword; otherwise, the original candidate fragment is directly retained as the final keyword; a list of keywords that have had negative expressions removed and express true needs is generated and associated with the original offset for use in subsequent attribute analysis steps. The attitude label is a macro-level stance indicator for the user's entire statement of housing needs. Its values ​​include accept, reject, or neutral. Accept indicates the user explicitly "want / hopes / must" a certain characteristic; reject indicates the user explicitly "does not / excludes / refuses" a certain characteristic; and neutral indicates the user merely states a fact without a clear acceptance or rejection inclination. This label can serve as a routing switch for the subsequent "reverse correction" process, determining whether to negate the attitude-targeted entity. The attitude-targeted entity is the smallest semantic unit directly associated with the attitude label, representing the specific object the user "accepts" or "rejects." It can be a continuous substring of the original text, or... It can be a standardized stem, for example, in "Don't look for a house where you can't keep cats," the attitude refers to the entity "can't keep cats," and in "Preferably with an elevator," the referencing entity is "with an elevator." This entity serves as the target point for reverse correction, used to determine the keyword fragments that need to be reversed or retained. The user's true positive demand description is the core user demand re-expressed in an affirmative sentence after removing negative expressions. For example, when inputting "Refuse to keep cats," the true positive demand description is "can keep cats," and when inputting "Don't face north," it is described as "face south, east, or west." This user's true positive demand description is used to guide the inversion generation in the keyword splitting stage, ensuring that the final keywords directly reflect the user's true needs. The original offset refers to the character-level position information of the keyword in the user's original input text, that is, the starting and ending character indices of the keyword in the entire sentence of housing demand information. For example, for the input text "I want to find a three-bedroom house where I can keep cats," the original offset of the keyword "can keep cats" can be represented as [3, 6], indicating that the word starts from the 3rd character and ends at the 6th character. This embodiment utilizes a deep intent inference and reverse correction mechanism to achieve negative semantic disambiguation and positive demand conversion on the input side. This ensures that subsequent differentiated processing flows obtain unbiased and accurate keyword sources, thereby playing a decisive role in the front-end of high-precision and low-latency collaborative optimization and laying a prerequisite foundation for improving the overall accuracy and efficiency of property search.

[0038] Step 202 above involves performing attribute analysis on each keyword and determining the reasoning depth type of each keyword based on the attribute analysis results, to obtain at least one first keyword belonging to the reasoning type and at least one second keyword belonging to the non-reasoning type. Optional implementation methods include: first, performing dependency analysis on each keyword to obtain syntactic attributes; second, querying a preset business semantic role dictionary to obtain semantic attributes; and third, reading an in-memory inverted index to obtain business scarcity attributes. Dependency analysis refers to the process of identifying and labeling the dominance and subordination relationships between keywords and outputting dependency arcs (such as subject-verb, verb-object, adverbial, etc.), i.e., relation type labels; syntactic attributes refer to the set of syntactic features used to determine whether a keyword has spatial, temporal, or other characteristics requiring further reasoning. This set of syntactic features includes, but is not limited to: dependency arc type (such as obl, amod, nmod, etc.), headword part of speech, and whether it is in a negative modification position; the business semantic role dictionary refers to an offline-built semantic tag library specific to the housing resource domain, stored in memory in the form of a hash table or Double-Array Trie, with each record containing <words or phrases, Role Tags > Role tags are limited to high-value business dimensions such as commuting, school district, budget, pets, apartment type, and amenities. The longest matching role is returned during the query; if no role is matched, nothing is returned. Semantic attributes refer to zero or more role tags obtained after matching keywords with the business semantic role dictionary, as well as whether they are marked with higher-order semantic tags such as "implicit distance, area, and amount conversion." These semantic attributes are used to quickly identify whether geographical or numerical reasoning is needed. The in-memory inverted index refers to a memory-level inverted structure built at system startup using historical query logs and property database fields. The key is the stem after word segmentation, and the value is the normalized Inverse Document Frequency (IDF) and the click-through rate (CTR) of properties in the past N days. The product of Rate (CTR) weights supports O(1) reads and is used to quantify the business scarcity of keywords. N≥1 and is an integer. The business scarcity attribute refers to the comprehensive weight of IDF×CTR read from the inverted index in memory. The higher the weight, the rarer the word is in the property description information and the higher the user click rate. This business scarcity attribute is used to suppress low-value words from entering the inference channel in the deterministic decision-maker and implement a conservative strategy.Subsequently, syntactic attributes, semantic attributes, and business scarcity attributes are input into the deterministic determiner. Based on preset if-else rules, the inference depth type label for the keyword is output in real time, resulting in at least one first keyword belonging to the inference type and at least one second keyword belonging to the non-inference type. These are used for subsequent large model slot filling and small model slot filling, respectively. The if-else rule refers to a hard-coded condition sequence embedded in the deterministic rule engine, accepting syntactic, semantic, and business scarcity attributes as input and outputting a "inference type" or "non-inference type" label. It has no machine learning parameters and supports hot updates. This embodiment achieves parallel parsing of syntax, semantics, and business scarcity at the keyword level through three-level attribute fusion and a deterministic determiner. This ensures that subsequent differentiated slot filling obtains keyword sources with conflict-free attributes and accurate inference depth labeling. This plays a core role in high-precision and low-latency collaborative optimization and aggregation, laying the foundation for improving the overall accuracy and efficiency of property search.

[0039] Step 203 above, which determines the importance of at least one inference keyword, can be implemented in the following ways: calculating the basic statistical score, scenario hit score, and personalized preference score of at least one inference keyword; calculating the first business relevance score corresponding to at least one inference keyword based on the basic statistical score, scenario hit score, and personalized preference score of at least one inference keyword; and determining the importance of at least one non-inference keyword based on the first business relevance score corresponding to at least one inference keyword.

[0040] The basic statistical score reflects the scarcity and business value of inferential keywords in the historical data of the entire property listing platform. The basic statistical score is determined by the inverse document frequency (IDF) of the inferential keyword in the property query log and the property click weight. For example, the basic statistical score is determined by multiplying the inverse document frequency of the inferential keyword by the property click weight. A higher score indicates that the inferential keyword is rarer and more important to users. The inverse document frequency reflects the scarcity of the inferential keyword in the entire query space and can be calculated as follows: IDF = In(Total queries ÷ Query count containing this keyword + 1). A larger result indicates a lower frequency of occurrence of the inferential keyword and higher distinguishability. The property click weight reflects the relative attractiveness of the properties associated with the inferential keyword in historical exposures and can be calculated as follows: Property click weight = Number of clicks on properties with the inferential keyword ÷ Number of exposures of properties containing the inferential keyword. A higher value indicates that the properties corresponding to the inferential keyword are more favored by users and have greater business value. The scenario hit score measures the immediate matching degree between inferential keywords and current property listing information. It is determined by the explicit match degree and matching position weight of the inferential keyword in the current user session. A perfect score is awarded if the inferential keyword appears in its entirety; the next highest score is awarded if a synonym appears; and zero score is awarded if it does not appear at all. The personalized preference score reflects the deviation of the inferential keyword from the user's historical preferences. The personalized preference score is determined by the user's interest in the property corresponding to the inferential keyword, or in other words, by the explicit match degree and matching position weight of the inferential keyword in the current user session. Explicit match degree measures the strength of overlap between the user's query text and the property listing field. It is scored only when the inferential keyword appears completely and continuously in the property title, description, or tags. For example, a perfect match (keyword and field content are identical word-for-word) scores 1; a prefix / suffix match (keyword is at the beginning or end of the field) scores 0.8; a substring match (the inferential keyword is contained but not at the beginning or end) scores 0.6; and no match scores 0. This score is used in the initial screening stage to quickly amplify intuitive relevance. Match position weight refers to further measuring the importance of the keyword's location based on explicit matching. For example, to reflect business prioritization, the title area has a weight of 1; core tags (such as "subway entrance" and "south-facing") have a weight of 0.9; the first sentence of the details text has a weight of 0.7; other locations in the details text have a weight of 0.5; and attribute fields only (such as "area 90㎡") have a weight of 0.3. The position weight is multiplied by the explicit matching degree to obtain the position sensitive matching score, which is used to prioritize the exposure of listings with titles and core tags in the ranking stage, thereby improving the click-through rate of the first few results.

[0041] Optionally, based on the basic statistical score, scenario hit score, and personalized preference score of at least one inference keyword, a first business relevance score corresponding to at least one inference keyword is calculated, including: linearly weighting the basic statistical score, scenario hit score, and personalized preference score according to preset weights α, β, and γ to obtain the importance score of at least one inference keyword, which is used as the first business relevance score corresponding to at least one inference keyword.

[0042] In step 204 above, at least one primary keyword is sorted according to its importance to obtain a first sorting result. That is, the sorting of at least one primary keyword is not a simple sequential order, so that each slot in the subsequent non-reasoning slot template is more in line with the actual business priority.

[0043] The above-mentioned 205, based on the first sorting result, generates a reasoning slot template, and its further implementation includes: generating reasoning slots and their arrangement order based on the first sorting result, and generating a reasoning slot template based on the reasoning slots and their arrangement order.

[0044] Accordingly, step 206 above, determining the importance of at least one second keyword, can be implemented in the following ways: calculating the basic statistical score, scenario hit score, and personalized preference score of at least one non-reasoning keyword; calculating the second business relevance score corresponding to at least one non-reasoning keyword based on the basic statistical score, scenario hit score, and personalized preference score of at least one non-reasoning keyword; and determining the importance of at least one non-reasoning keyword based on the second business relevance score corresponding to at least one reasoning keyword. For the specific implementation methods and terminology of steps 206-208, please refer to the relevant descriptions in steps 203-205 above, which will not be repeated here.

[0045] The above Figure 1bThe technical solution provided in the relevant embodiments adopts a three-dimensional scoring mechanism of "basic statistics - scene hit - personalization" to quantitatively integrate the scarcity, immediate relevance, and user preference of inference-type and non-inference-type keywords within the same feature space, thereby generating a first business relevance score and a second business relevance score. Based on these scores, the importance of keywords can be assessed, thereby guiding the order and position arrangement of slot filling, effectively improving slot filling efficiency and laying the foundation for improving the accuracy and efficiency of overall property search. Furthermore, the first and second business relevance scores free the admission thresholds for inference-type and non-inference-type keywords from dependence on human experience and directly drive the diversion decision between the large and small models, ensuring that high-value, high-matching, and high-user-preference terms are prioritized for entry into the deep inference channel of the large model, while low-value terms are quickly transferred to the rule channel for processing. This mechanism achieves the optimal configuration of computing power and inference accuracy without introducing additional computing power overhead, thus building a quantitative diversion foundation for improving the accuracy and efficiency of overall property search.

[0046] In this embodiment, all first keywords belonging to the reasoning type may belong to the same reasoning task or different reasoning tasks. If multiple first keywords belong to the same reasoning task, they can share a single chain of reasoning; if they belong to different reasoning tasks, different chain of reasoning is required, and different reasoning tasks or chain of reasoning correspond to different sub-templates. For example, if the housing demand information contains both "20 min to location A" and "convenient for dog walking," the system will first split it into different sub-templates according to the task type, and trigger a chain of reasoning for each type of sub-template. Subsequently, each chain of reasoning is executed in parallel, calling the corresponding functions respectively, and finally merging the results generated by each chain of reasoning into the same structured parameters. During the merging process, the intermediate results generated by multiple chain of reasoning are written back to JSON all at once, maintaining a single model call output and not increasing the number of additional requests. In short, each sub-task requiring independent reasoning corresponds to a chain of reasoning, rather than each keyword corresponding to a separate chain of reasoning.

[0047] In response, step 103 above inputs the first keyword belonging to the reasoning type and the reasoning slot template into the second large language model, and uses chain-like thinking and function calls to fill the slots of the reasoning slot template to obtain the reasoning structured parameters. Optional implementation methods include: inputting the first keyword belonging to the reasoning type and the reasoning slot template into the second large language model, and triggering the following chain-like thinking calls: if all first keywords belong to the same reasoning task, then all first keywords are merged into a single thought chain information, and this thought chain information is used to gradually parse the implicit semantics of the first keywords, generating at least one intermediate reasoning result; if at least some of the first keywords belong to the same reasoning task, then... If the keywords represent different reasoning tasks, the reasoning slot template is split into sub-templates corresponding to different reasoning tasks according to the reasoning task type, and a thought chain information is generated for each sub-template. For any thought chain information, the implicit semantics of the corresponding first keyword are parsed step by step according to the thought chain information to generate at least one intermediate reasoning result. A preset function is called to convert at least one intermediate reasoning result corresponding to any thought chain information into executable parameter values, and the executable parameter values ​​are written into the corresponding fields of the corresponding sub-template to obtain the local reasoning structured parameters corresponding to the sub-template. The local reasoning structured parameters corresponding to each sub-template are merged to obtain the reasoning structured parameters. Among them, the intermediate reasoning result refers to the intermediate semantic and numerical units generated by a chain of reasoning in any single-step derivation stage, used to narrow the solution space or for subsequent steps to continue to call. Its form includes, but is not limited to: semantic labels (transportation mode = subway); numerical quantities (radius = 3200 m); parameter packets that the function can accept ({center:, radius:}); and logical assertions that have constraints on subsequent reasoning ("feasible areas must exclude highway sections"). In short, intermediate inference results are not the final slot values, but they are necessary to derive the final slot values, thus constituting "at least one intermediate inference result".

[0048] The above embodiments utilize a "task-level decomposition + sub-template parallel chain thinking" mechanism to simultaneously call the same large model for different inference needs. Each sub-task independently generates intermediate semantic and numerical units and performs parallel functionalization, ultimately merging them into a single structured parameter. This approach completes multiple types of complex inference within a single request, avoiding network and computing power overhead caused by repeated calls. It ensures the recall accuracy of high-value inference fields while keeping the overall response time controllable. Thus, it plays a core role in the collaborative optimization of high accuracy and low latency, laying a deep inference foundation for improving the overall accuracy and efficiency of housing search.

[0049] If all first keywords are for the same reasoning task, the implicit semantics of the first keywords are parsed step by step using the thought chain information to generate at least one intermediate reasoning result. Optional implementation methods include: when the implicit semantics of any first keyword are multiple semantics, the parsing process of any first keyword is divided into multiple sub-steps equal to the number of its implicit semantics based on the parsing steps contained in the thought chain information; parsing the implicit semantics corresponding to each sub-step; generating multiple intermediate reasoning results based on the implicit semantics corresponding to each sub-step; and when the implicit semantics of any first keyword are a single semantic, the implicit semantics of any first keyword are parsed step by step using chain-like thinking to generate one intermediate reasoning result.

[0050] If at least some of the first keywords are different reasoning tasks, the reasoning slot template is split into sub-templates corresponding to different reasoning tasks according to the reasoning task type. The optional implementation methods include: labeling the first keywords with tasks through a preset task classification table to obtain task types, such as commuting, matching, school district or pet task types; splitting the reasoning slot template horizontally into non-overlapping sub-templates according to the task type, with each sub-template retaining only the fields required for the same type of task to form an independent reasoning channel.

[0051] Optionally, a thought chain information is generated for each sub-template, including: outputting semantic tags, intermediate values ​​and function parameter packages in sequence based on the same reasoning task sub-template and its first keyword; appending the result of each step as a JSON fragment to the same response stream to form a parsable chain of thought records, which is used to drive subsequent function calls to complete slot filling.

[0052] The above implementation employs a "multi-step chain-like thinking" approach to decompose complex implicit semantics step by step within the same inference task. Between different inference tasks, it uses "task-level sub-template splitting + parallel chain-like thinking" to achieve one-time model invocation for heterogeneous requirements. The combination of the two ensures that regardless of changes in semantic complexity or task type, a complete intermediate inference result can be generated within a single request and the function conversion can be completed synchronously. This mechanism avoids repeated invocations and context confusion, significantly reduces computational overhead while improving the accuracy of complex requirement parsing. Thus, it plays a decisive role in deep inference in the collaborative optimization of high accuracy and low latency, laying a multi-task parallel foundation for improving the overall accuracy and efficiency of housing search.

[0053] In an optional embodiment, step 106 above, which maps the target structured intent parameters to a property search statement, performs a property search using the inference type fields in the property search statement as the main query condition and the non-inference type fields as the filtering query conditions to obtain a target property set, includes: mapping the slot name, first keyword, and second keyword in the target structured intent parameters to the query fields one-to-one based on preset query fields to obtain a property retrieval statement executable by the property platform, wherein the first keyword can be mapped to an inference type field and the second keyword can be mapped to a non-inference type field; performing a property search on the property platform using the inference type fields in the property search statement as the main query condition to obtain a candidate property set; and performing a filtering search on the candidate property set using the non-inference type fields in the property search statement as the filtering query conditions to obtain the target property set.

[0054] This embodiment achieves decoupling of recall relevance and computational overhead through a two-level search strategy of "primary search of inference fields + filtering of non-inference fields". Furthermore, this mapping and hierarchical mechanism ensures that high-value properties are given priority in entering the candidate property set, and low-value properties are screened early, thereby improving the hit rate of the first round of results with zero additional computing power, laying the foundation for the retrieval strategy to improve the overall accuracy and efficiency of property search.

[0055] Furthermore, during the process of obtaining the target property list, the system can also receive supplementary property requirements from users. Accordingly, after obtaining the target property list, it can be further filtered based on the supplementary requirements to obtain property information to be recommended. Finally, this recommended property information can be displayed to the user for selection.

[0056] This embodiment introduces a supplementary requirement secondary filtering mechanism after the first round of results are returned. The fine-grained conditions added by the user (floor, orientation, amenities, etc.) are instantly mapped to filtering conditions. A lightweight intersection operation is performed on the existing target property set without re-triggering a full property recall. While maintaining low latency, this process further compresses the candidate scale and improves the relevance of the requirements, realizing a progressive property search experience of "chatting and filtering at the same time". This lays an interactive iterative foundation for the sustainable optimization of the overall property search accuracy and efficiency.

[0057] Furthermore, to reduce computing power and response time, a template library can be maintained on the housing platform. The template library can store historical housing demand information and its corresponding historical inference-type slot templates and non-inference-type slot templates. When new housing demand information is received, the platform can first check the template library to see if there is a historical inference-type slot template and / or non-inference-type slot template that matches the new housing demand information. If it exists, it can be selected directly without regenerating. If it does not exist, a new inference-type slot template and / or inference-type slot template will be regenerated.

[0058] Based on this Figure 1c An exemplary flowchart of another slot template generation method is provided. (See reference) Figure 1c Before generating inference-based and non-inference-based slot templates that match the housing demand information based on the inference depth type of multiple keywords contained in the housing demand information, the following operations can also be performed: 301. Match the historical reasoning slot templates and / or historical non-reasoning slot templates required for housing demand information from the template library. The template library stores historical housing demand information and historical reasoning slot templates and historical non-reasoning slot templates that are adapted to each historical housing demand information. 302. If a match is found, there is no need to regenerate the reasoning-based slot template and / or non-reasoning-based slot template that are adapted to the housing demand information. Instead, the historical reasoning-based slot template and / or historical non-reasoning-based slot template that are matched will be used as the reasoning-based slot template and / or non-reasoning-based slot template that are adapted to the housing demand information. 303. If no match is found, then based on the reasoning type of multiple keywords contained in the housing demand information, generate reasoning-type slot templates and / or non-reasoning slot templates that are adapted to the housing demand information, and associate and store the housing demand information and the reasoning-type slot templates and / or non-reasoning slot templates that are adapted to the housing demand information in the template library.

[0059] In addition, the template library can be periodically integrated and optimized based on changes in housing demand information or business scenarios to improve the accuracy of template matching. For example, housing demand information that has not been matched within a preset time period, along with its corresponding inference-based and / or non-inference-based slot templates, can be deleted. Another example is that, if the business scenario changes, housing demand information related to the previous business scenario, along with its corresponding inference-based and / or non-inference-based slot templates, can be deleted. However, this is merely an example and does not constitute a limitation on the solution proposed in this application.

[0060] This embodiment introduces a "historical template library - incremental matching" mechanism before generating slot templates. For requests that match historical data, existing inference / non-inference slot templates are directly reused, saving one model call. For requests that do not match, inference / non-inference slot templates are generated immediately and written back to the library. Simultaneously, low-frequency and outdated scenarios are periodically cleaned up to maintain library size convergence. This hot / cold tiering strategy significantly reduces the average response time for high-frequency requests and adaptively updates as business evolves, ensuring that slot templates always align with the current user expression distribution. This continuously reduces computational overhead while laying an evolvable foundation for improving the overall accuracy and efficiency of property search.

[0061] For ease of understanding, the technical solutions presented in the above embodiments of this application are summarized and described below.

[0062] The property search method involved in this application mainly involves four stages, as follows: Phase 1: Template Generation Phase The first language model extracts keywords from the user's natural language input of housing demand information and determines its inference depth type. Then, based on the business relevance score, it determines the order of each slot in two slot templates and outputs two "semi-structured skeletons". One "semi-structured skeleton" corresponds to the inference-type slot template, and the other "semi-structured skeleton" corresponds to the non-inference-type slot template. That is, it only declares which slots are required in the corresponding slot template, the field names, data types, required flags and weights of each slot, without presetting any final parameter values ​​or fixing the mapping relationship from keywords to values, thus maintaining openness to subsequent context changes.

[0063] Phase Two: Slot Filling Phase After the inference-based slot templates and non-inference-based slot templates enter the two parallel channels respectively, the transformation functions dynamically generated by the engine corresponding to each template obtain the parameters corresponding to the key information of each keyword. Specifically, the transformation functions of the inference-based slot templates are registered in the controlled callable function list (or tool registry) of the second large language model in the form of callable operators. The second large model concatenates the parameters and calls them in real time when the slots are filled (such as isochronous circles and policy parsing); while the transformation functions corresponding to the non-inference-based slot templates are regular expressions, dictionaries, if-else statements, or lookup tables in the lightweight rule engine, which are also executed at the moment of filling (such as price truncation and synonym mapping). Furthermore, during the slot filling process, inference-type slots are executed on-site by the second major language model through chained thinking and function calls, such as instantly calculating "20 minutes to location A" into the latitude and longitude range of the isochronous circle. It should be noted that the conversion function and the corresponding conversion result are different for the same keyword when the application scenario and needs are different (different cities, different needs, different departure points). Non-inference-type slots are captured by the lightweight rule engine through regular expression capture, dictionary lookup, or numerical normalization. For example, "8000 yuan" is truncated, rounded, and mapped to rent_max=8000. These mapping functions of "keyword → key information → standardized parameters" are dynamically generated in milliseconds or hundreds of milliseconds to ensure that the same keyword can obtain different but ultimately usable parameter values ​​in different cities and different user scenarios.

[0064] Phase 3: Generation of Target Structured Intent Parameters By fusing inference-based and non-inference-based structured parameters, target structured intent parameters are obtained; Phase Four: Property Search Phase The target structured intent parameters are mapped to property search statements. Property searches are performed using inference fields in the property search statements as the main query conditions and non-inference fields as the filter query conditions to obtain the target property set.

[0065] At this point, the property search method has been completed. The technical solution provided by this property search method improves the accuracy of intent recognition, thereby increasing the accuracy and efficiency of property search.

[0066] Figure 2 A schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. For example... Figure 2 As shown, the electronic device includes: a memory 20a and a processor 20b; the memory 20a is used to store a computer program; the processor 20b, coupled to the memory 20a, is used to execute the computer program to perform the following steps: The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0067] Furthermore, such as Figure 2 As shown, the electronic device also includes other components such as a communication component 20c, a display 20d, a power supply component 20e, and an audio component 20f. Figure 2 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 2 The components shown.

[0068] in addition, Figure 2 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server-side device such as a conventional server, cloud server, or server array. If the electronic device in this embodiment is a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 2 The components within the dashed box; if the electronic device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., it may be omitted. Figure 2 The component within the dashed box.

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

[0070] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 6G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

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

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

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

[0074] Accordingly, an exemplary embodiment of this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the steps in the above-described method.

[0075] Accordingly, an exemplary embodiment of this application also provides a computer program product comprising a computer program / instructions that, when executed by a processor, cause the processor to perform the steps in the above-described method.

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

[0077] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0078] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0079] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0080] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0081] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0082] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

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

Claims

1. A method for searching housing listings, characterized in that, include: Obtain housing demand information input by users in natural language format; Input the housing demand information into the first language model. Based on the reasoning depth type of multiple keywords contained in the housing demand information, generate reasoning slot templates and non-reasoning slot templates that are adapted to the housing demand information. The reasoning depth type includes reasoning type and non-reasoning type. Input at least one primary keyword belonging to the reasoning type and the reasoning slot template into the second language model, and use chain thinking and function call to fill the slots of the reasoning slot template to obtain the reasoning structured parameters. Input at least one second keyword belonging to the non-reasoning type and the non-reasoning slot template into the lightweight model, and fill the slots of the non-reasoning operation template based on the preset slot filling rules to obtain the non-reasoning structured parameters. By fusing inference-based and non-inference-based structured parameters, target structured intent parameters are obtained; The target structured intent parameters are mapped to property search statements. Property searches are performed using inference fields in the property search statements as the main query conditions and non-inference fields as the filter query conditions to obtain the target property set.

2. The method according to claim 1, characterized in that, Input the housing demand information into the first language model. Based on the inference depth type of multiple keywords contained in the housing demand information, generate inference-based slot templates and non-inference-based slot templates adapted to the housing demand information, including: Input the housing demand information into the first language model, and break down the housing demand information into keywords according to the overall intent corresponding to the housing demand information to obtain multiple keywords; Perform attribute analysis on each keyword, and determine the reasoning depth type of each keyword based on the attribute analysis results, so as to obtain at least one first keyword belonging to the reasoning type and at least one second keyword belonging to the non-reasoning type; Determine the importance of at least one primary keyword; sort the at least one primary keyword according to its importance to obtain a first sorting result; generate an inference-type slot template based on the first sorting result; as well as Determine the importance of at least one secondary keyword; sort the at least one secondary keyword according to its importance to obtain a second sorting result; generate a non-reasoning slot template based on the second sorting result.

3. The method according to claim 2, characterized in that, Determine the importance of at least one inferential keyword, including: Calculate the basic statistical score, scenario hit score, and personalized preference score of at least one inference keyword; based on the basic statistical score, scenario hit score, and personalized preference score of at least one inference keyword, calculate the first business relevance score corresponding to at least one inference keyword; based on the first business relevance score corresponding to at least one inference keyword, determine the importance of at least one non-inference keyword; Accordingly, the importance of at least one secondary keyword is determined, including: Calculate the basic statistical score, scenario hit score, and personalized preference score of at least one non-inference keyword; based on the basic statistical score, scenario hit score, and personalized preference score of at least one non-inference keyword, calculate the second business relevance score corresponding to at least one non-inference keyword; based on the second business relevance score corresponding to at least one inference keyword, determine the importance of at least one non-inference keyword.

4. The method according to claim 1, characterized in that, The first keyword belonging to the reasoning type and the reasoning slot template are input into the second language model. Chain-like thinking and function calls are used to fill the slots in the reasoning slot template to obtain the reasoning structured parameters, including: Inputting the first keyword belonging to the reasoning type and the reasoning slot template into the second language model triggers the following chain of thought processes: If all the first keywords belong to the same reasoning task, then all the first keywords are merged into a single thought chain information, and the implicit semantics of the first keywords are gradually parsed using this thought chain information to generate at least one intermediate reasoning result. If at least some of the first keywords are for different reasoning tasks, the reasoning slot template is split into sub-templates corresponding to different reasoning tasks according to the reasoning task type, and a thought chain information is generated for each sub-template. For any thought chain information, the implicit semantics of the corresponding first keyword are parsed step by step according to any thought chain information to generate at least one intermediate reasoning result. A preset function is called to convert at least one intermediate reasoning result corresponding to any thought chain information into an executable parameter value, and the executable parameter value is written into the corresponding field of the corresponding sub-template to obtain the local reasoning structured parameters corresponding to the sub-template. The local reasoning structured parameters corresponding to each sub-template are merged to obtain the reasoning structured parameters.

5. The method according to claim 4, characterized in that, By using the information from the thought chain to progressively parse the implicit semantics of the first keyword, at least one intermediate reasoning result is generated, including: When the implicit semantics of any first keyword are multiple, based on the parsing steps in the thought chain information, the parsing process of any first keyword is divided into multiple sub-steps with the same number of implicit semantics; the implicit semantics corresponding to each sub-step are parsed; and multiple intermediate inference results are generated based on the implicit semantics corresponding to each sub-step. When the implicit semantics of any first keyword are single, the implicit semantics of any first keyword are analyzed step by step using chain thinking to generate an intermediate reasoning result.

6. The method according to claim 1, characterized in that, The target structured intent parameters are mapped to property search statements. Property searches are performed using inference-type fields from the property search statements as the main query conditions and non-inference-type fields as filter query conditions, resulting in a target property set, including: Based on the preset query fields, the slot name, first keyword and second keyword in the target structured intent parameters are mapped one by one with the query fields to obtain the property search statement that the property platform can execute; the first keyword is mapped to the inference type field and the second keyword is mapped to the non-inference type field. Using the reasoning type field in the property search statement as the main query condition, a property search is performed on the property platform to obtain a set of candidate properties. The candidate property list is filtered and searched using non-reasoning fields in the property search query as filtering conditions to obtain the target property list.

7. The method according to any one of claims 1-6, characterized in that, Also includes: During the process of obtaining the target housing list, the system receives supplementary housing demand information provided by the user. After obtaining the target property list, the target property list is filtered based on the supplementary property demand information to obtain property information to be recommended; Show users the property listings that are to be recommended.

8. The method according to any one of claims 1-6, characterized in that, Before generating inference-based and non-inference-based slot templates adapted to the housing demand information based on the inference depth type of multiple keywords contained in the housing demand information, the process also includes: Match historical inference-type slot templates and / or historical non-inference-type slot templates required for housing demand information from the template library. The template library stores historical housing demand information and historical inference-type slot templates and historical non-inference-type slot templates that are adapted to each historical housing demand information. If a match is found, there is no need to regenerate the reasoning-based slot template and / or non-reasoning-based slot template that are adapted to the housing demand information. Instead, the historical reasoning-based slot template and / or historical non-reasoning-based slot template that are matched will be used as the reasoning-based slot template and / or non-reasoning-based slot template that are adapted to the housing demand information. If no match is found, then based on the reasoning type of multiple keywords contained in the property demand information, generate reasoning-type slot templates and / or non-reasoning slot templates that are adapted to the property demand information, and store the property demand information and the reasoning-type slot templates and / or non-reasoning slot templates that are adapted to the property demand information in the template library.

9. An electronic device, characterized in that, include: Memory and processor; Memory, used to store computer programs; A processor, coupled to memory, for executing a computer program to implement the steps of any one of claims 1-8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it causes the processor to perform the steps of any one of the methods of claims 1-8.

11. A computer program product, characterized in that, The computer program product includes a computer program / instructions that, when executed by a processor, cause the processor to perform the steps of any one of the methods of claims 1-10.

Images