House resource recommendation method and device and storage medium

Abstract

The embodiment of the invention provides a house resource recommendation method and device and a storage medium, and relates to the technical field of computers.The method comprises the steps that a house finding demand input by a user is received, an intention corresponding to the house finding demand is recognized as a commuting type house finding intention, and therefore multiple candidate house resources are screened out from a platform house resource library; determining one or more verification dimensions according to the commuting type house finding intention, and according to the priority sequence of the verification dimensions, performing multi-level layered verification on the plurality of candidate house resources in sequence, and judging whether the candidate house resources meet the verification condition and the fault-tolerant condition of any verification dimension or not; and adding the candidate house resources meeting the verification conditions of the verification dimensions and the candidate house resources which do not meet the verification conditions of part of the verification dimensions but meet the corresponding fault-tolerant conditions into a recommended house resource set, and outputting a recommendation result to the user. On the basis of the method, the recommendation accuracy can be improved, and the problems that house pushing is not conducted when houses exist and house pushing is inaccurate are effectively solved.

Description

Technical Field

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

[0002] With rapid urbanization, commuting to find housing constitutes a significant portion of users' housing needs. However, current real estate platforms primarily match listings through user-initiated filtering or pre-set quick filters. Users must manually combine filtering criteria to narrow down their search, which is cumbersome. To address this, some platforms offer AI-powered housing search services, recommending properties after users describe their housing needs. However, as users' housing needs become increasingly personalized, scenario-based, and complex, there is a growing disconnect between the platform's recommended properties and users' actual needs. Summary of the Invention

[0003] This application provides a method, device, and storage medium for recommending properties, which can improve the accuracy of property recommendations and enhance user experience.

[0004] In a first aspect, embodiments of this application provide a method for recommending housing listings, the method comprising: The system receives user input regarding their housing search needs and performs intent parsing to identify commuting-related intents. Based on this intent, it filters multiple candidate properties from the platform's property database. It then determines one or more verification dimensions based on the commuting intent and performs multi-level hierarchical verification on the candidate properties according to their priority. This multi-level hierarchical verification includes: determining whether a candidate property meets the verification conditions for any of the verification dimensions; and if not, determining whether it meets the corresponding tolerance conditions for any of the verification dimensions. Candidate properties that meet the verification conditions for all verification dimensions, as well as those that do not meet some verification dimensions but meet the corresponding tolerance conditions, are added to a recommended property set. Finally, recommendations are output to the user based on this recommended property set.

[0005] Secondly, embodiments of this application also provide an electronic device, including: a memory and a processor; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the method described in the first aspect.

[0006] Thirdly, embodiments of the present invention provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the method described in the first aspect.

[0007] Fourthly, embodiments of the present invention provide a computer program product, the computer program product including a computer program or instructions, which, when executed by a processor, cause the processor to implement the method described in the first aspect above.

[0008] In summary, this application provides a housing recommendation method. By identifying commuting-related housing search intentions, it constructs one or more verification dimensions to match them, and performs verification on candidate housing listings based on these dimensions. This effectively filters out housing listings that are clearly inconsistent with the user's commuting needs, thereby ensuring that the recommendation results are more in line with the user's true intentions and significantly improving recommendation accuracy. Furthermore, the method provided in this application adopts a multi-level hierarchical verification mechanism, performing judgments sequentially according to the priority order of each verification dimension. This ensures that more important verification dimensions are verified first, and secondary verification dimensions are subsequently verified. This makes the verification logic hierarchical and efficient, allowing for faster elimination of obviously mismatched housing listings, reducing invalid calculations, and ensuring that core needs are met first, thus improving the overall recommendation quality. Furthermore, the method provided in this application introduces fault tolerance conditions. Even if a candidate property does not meet the strict verification conditions of a certain verification dimension, it can still be retained in the recommendation set according to the preset reasonable fault tolerance conditions. This avoids the problem of properties not being recommended due to a single hard rule, and takes into account both the rigor and flexibility of the recommendation. It avoids the misscreening of high-quality potential properties and expands the effective recommendation range, significantly improving user satisfaction and the exposure and conversion efficiency of platform properties. Attached Figure Description

[0009] 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 1 This is a schematic diagram of a housing recommendation scenario provided in an embodiment of this application; Figure 2 A flowchart illustrating a housing recommendation method provided in an embodiment of this application; Figure 3 This is a schematic diagram of a housing recommendation device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0010] 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.

[0011] 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.

[0012] In today's rapidly urbanizing world, commuting to find housing constitutes a significant portion of users' housing needs. However, current real estate platforms primarily match listings based on user-initiated filtering (such as price, location, and apartment type) or pre-set, fixed quick filters (such as proximity to subway or elevator access). Users must manually combine filtering criteria to narrow down their search, which is cumbersome. To address this, some platforms offer AI-powered housing search services, recommending listings after users describe their housing needs. However, as user housing needs become increasingly personalized, scenario-based, and complex, existing listing recommendations suffer from several problems: platforms cannot accurately quantify and dynamically calculate unstructured needs, leading to misunderstandings of user requirements. This results in listings that don't match the user's actual needs, requiring users to verify the accuracy of the recommendations. Furthermore, persistent recommendation discrepancies lead users to perceive the platform's recommendations as inaccurate or unreliable. If users frequently find the recommendations deviating from their expectations, they gradually lose trust in the platform's functionality, ultimately leading to decreased user activity or even churn. For example, if a user enters their housing search requirement as "30-minute commute by public transport," the platform's analysis of such vague requirements is insufficient. Consequently, key requirements such as commute time and mode of transportation are not effectively incorporated into the recommendation logic. The platform may recommend properties that exceed the commute time limit, requiring users to verify the recommendations themselves and potentially leading to feelings that the platform's recommendations are inaccurate.

[0013] In view of this, this application provides a housing recommendation method. Through precise intent recognition, it parses user housing search needs into commuting-related and non-commuting-related intents. Then, based on user housing search needs, it retrieves multiple candidate housing listings and performs multi-level hierarchical verification on these commuting-related candidate listings. Simultaneously, it introduces a fault-tolerance mechanism, including some listings that have not fully passed verification but have stable historical performance in the recommendations. Finally, it generates a recommendation set to ensure that the recommended housing meets user needs, improves recommendation accuracy, reduces invalid user browsing, and enhances user experience. Furthermore, the multi-level hierarchical verification and fault-tolerance mechanism can improve accuracy while avoiding the situation where qualified housing is mistakenly filtered out (i.e., not recommended even when available) due to reliance on a single condition, thus balancing accuracy and robustness.

[0014] The housing recommendation method provided in this application embodiment will be described in detail below with reference to the accompanying drawings.

[0015] Figure 1 A schematic diagram illustrating a scenario to which an embodiment of this application applies is shown. For example... Figure 1 As shown, the user's terminal device has a target application installed for users to find housing. Users can enter the AI ​​housing search page of the target application, initiate a conversation on the AI ​​housing search page, and describe their housing search needs, such as "within one hour of Dongzhimen subway station, whole apartment for rent under 5000 yuan, with elevator". The AI ​​housing search page can display recommended results, which are obtained based on the method provided in the embodiments of this application.

[0016] The terminal device can be a mobile phone, tablet computer, wearable device, in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.

[0017] The target application can be a traditional application. In this application embodiment, a functional module called the Artificial Intelligence (AI) interaction module is added to the traditional application. This module is responsible for expanding the AI ​​functions of the traditional application, enabling the traditional application to provide AI-powered house-finding services and supporting users to invoke the AI-powered house-finding services. The AI-powered house-finding services provide users with services such as chat, Q&A, and automatic recommendations.

[0018] Figure 2This illustration shows a flowchart of a housing recommendation method provided in an embodiment of this application. The method can be executed by a server, which can be deployed on a local device or server, or on a cloud server. Further, the server can be configured as a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server or cloud server cluster providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud storage, and big data and artificial intelligence platforms. Alternatively, this embodiment can also be executed by an AI interaction module. The AI ​​interaction module can interact with the server to call an AI model deployed on the server, or it can directly call the AI ​​model through an integrated AI model API. Figure 3 As shown, the property recommendation method includes the following steps S201-S205.

[0019] S201: Receive the user's housing search request, perform intent parsing on the housing search request, and identify the intent corresponding to the housing search request as a commuting-related housing search intent.

[0020] In this embodiment, the intent to find a property is categorized into commuting-related intent and non-commuting-related intent. Commuting-related intent includes commuting conditions and basic property attributes. Commuting conditions may include target location, commuting mode, commuting time, distance, and route, while basic property attributes include price, unit type, floor, and orientation. Non-commuting-related intent includes basic property attributes but does not include commuting conditions. Furthermore, commuting-related intent can be further subdivided into location-based search, nearby search, distance-based search, commuting-based search, district / business area search, and route-based search, etc.

[0021] Among these, "Point-of-Island (POI) Search" refers to users specifying a target location (POI) as their commuting destination, such as near the headquarters of a certain company, without specifying a commuting distance or time threshold. "Nearby Search" refers to users using vague terms like "nearby," "surrounding," or "next to" to describe the location relationship, such as "renting a place nearby." "Distance Search" refers to users explicitly specifying a commuting distance threshold, usually accompanied by a target location, such as "within 500 meters of the company." "Commuting Search" refers to users explicitly specifying a commuting time threshold and commuting method, such as "driving to the company within 30 minutes." "Administrative District / Business District Search" refers to users specifying an administrative district (e.g., Haidian District) or a business district (e.g., Zhongguancun) as their target area, without specifying a particular POI or commuting time. "Route Search" refers to users specifying a public transportation route (e.g., Metro Line 2, Bus Route 112) as their commuting route, requiring the property to be located along that route or near a stop. The commuting distance is the actual distance from the property to the target location using a specific commuting method while adhering to traffic rules. Commuting time refers to the actual time required to travel from the property to the destination using the desired mode of transportation.

[0022] After obtaining the user's housing search needs, these needs are populated into a carefully designed first prompt template, resulting in a first prompt. The first prompt guides the intent recognition model to accurately identify and classify the user's housing search intent and constrains the output format. Guided by the prompt, the intent recognition model can output structured parameters, such as {Intent Type: Commuting / Non-Commuting, Subtype: xxx, POI: xxx, Commuting Method: xxx,}. The subtype for non-commuting is none, while the slots for POI and commuting method are determined based on the actual subtype. For example, if a user inputs "Want to rent a house in Xujiahui," the intent recognition model outputs: {Intent Type: Commuting, Subtype: Administrative District / Business District Search, Area Name: Xujiahui, Area Type: Business District}. For example, if a user inputs "within 1 kilometer along Metro Line 2", the intent recognition model outputs: {Intent type: Commuting, Subtype: Route-based housing search, Area name: Metro Line 2, Commuting mode: Walking, Commuting distance threshold: 1000}.

[0023] Optionally, for some vague terms, such as "nearby" and "surrounding area," default logic can be used to fill in the missing information. Optionally, when a user's housing search needs are vague, details can be asked through dialogue. For example, if a user does not mention their commuting method in a commuting housing search, you can guide them by asking, "Do you mainly commute by subway or bus?"

[0024] Alternatively, the first prompt word template can be designed using structured instructions and few-shot examples. The first prompt word template includes first task description information, which describes the role played by the intent recognition model, the functions to be performed, and the constraints to be met when performing the functions. For example, it may include house-finding intent classification rules, subtypes of commuting house-finding, output format, and examples. The first prompt word template also includes a region to be filled, into which the house-finding requirement is filled to obtain the first prompt word.

[0025] By designing high-quality prompt word templates and constructing structured prompt words with examples, the intent recognition model is guided to accurately classify house-hunting intents during inference, thereby achieving precise parsing of commuting and non-commuting intents. The intent recognition model can be a model with intent recognition capabilities built based on a Large Language Model (LLM). The design of the prompt word templates enables the intent recognition model to efficiently and accurately distinguish between commuting and non-commuting house-hunting intents under zero-sample or few-sample conditions, and further subdivide commuting intents into subtypes.

[0026] Optionally, in some implementations, a user profile can be constructed, which may include static attributes, dynamic preferences, and contextual features. Static attributes may include, for example, occupation and family structure; dynamic preferences may include, for example, time-of-day preferences; and contextual features may include, for example, different commuting methods for different weather conditions and varying levels of acceptance of commuting time at different times of day.

[0027] During intent recognition, structured parameters are cross-referenced with dynamic user profiles to improve the completeness and accuracy of intent parsing. For example, when a user's text input is "a house within 30 minutes of Financial Street," the system automatically adds a parameter prioritizing subway commuting, based on the user profile's characteristics of internet professionals and historical reluctance to drive during morning rush hour.

[0028] S202 filters multiple candidate properties from the platform's property database based on the user's intention to find a place to live for commuting.

[0029] After obtaining the structured parameters corresponding to the user's housing search needs, multiple candidate properties are selected from the platform's housing database based on the structured parameters.

[0030] In some implementations, user housing search needs can be transformed into target locations and target radii. For example, in a business district housing search scenario, the core landmark of the business district is used as the target location, and the target radius is inferred based on information such as subtype, city attributes, and user profile. Then, with the target location as the center, the search area is expanded outward based on the target radius, and candidate properties are filtered within the expanded area.

[0031] For example, the expansion step size can be determined based on the target radius, the target range can be determined based on the expansion step size on the basis of the initial range, and candidate housing that meets the basic housing attributes can be selected from multiple communities within the target range.

[0032] In this embodiment, commuting is divided into short-distance and long-distance scenarios, with an initial range as the first threshold (e.g., a 3-kilometer range). In the short-distance scenario, the target radius includes a range that is less than or equal to the initial range, and the commuting differences between properties within the short distance are small. In this scenario, the expansion step size can be 0, and the target radius is used as the target range.

[0033] In long-distance scenarios, the target radius encompasses a larger area than the initial range. Commuting distances for properties vary significantly over long distances. Directly filtering by the target radius might include a large number of properties with excessive commuting distances. Therefore, this embodiment employs a dynamic expansion approach to filter properties. In this scenario, multiple candidate properties are initially selected within the initial range. If the number of candidate properties within the initial range does not meet the required output quantity, the range is expanded. During expansion, the expansion step size is determined, and the target range is determined based on this step size. After each expansion, candidate properties that meet the basic property attributes are retained. If the number of candidate properties obtained after this expansion meets the required output quantity, the expansion and calculation stop; otherwise, the next round of expansion and calculation begins.

[0034] In some implementations, the expansion method can be distance-based, with the expansion step size determined by the theoretical distance and the maximum number of expansions. An initial range can be determined first, and the expansion step size = (target radius - initial range) / maximum number of expansions. For example, if the initial range is 3 kilometers, the target radius is 13 kilometers, and the maximum number of expansions is 5, then the expansion step size is 2 kilometers. Based on the initial range, the radius is expanded outward by 2 kilometers each time. After the first expansion, the range is 5 kilometers, and after the second expansion, it is 7 kilometers. Furthermore, setting the maximum number of expansions or the expansion time can prevent the server from getting stuck in a loop; the specific settings can be configured according to the actual scenario.

[0035] Optionally, in some implementations, considering factors such as the density of urban housing and the location of the target site, the step size for each expansion can be appropriately adjusted. For example, the expansion step size determined by the target radius and the maximum number of expansions is used as the base step size. A correction factor is calculated for each expansion, and the corrected step size is determined based on the base step size and the correction factor. For instance, the corrected step sizes for distance expansion are 1 km, 2 km, 3 km, and 4 km.

[0036] In other implementations, the target location, user's housing search needs, and initial scope can be input into a pre-trained first model. The first model constructs a feature vector based on the input features, and uses the expansion patterns learned in the offline pre-training phase for different city features and user needs to generate multiple candidate step sizes. This triggers progressive constraint verification, and the expansion step size is dynamically determined based on the reward function. The model judges the validity of multiple candidate step sizes through the reward function, and then selects the better candidate step size. For example, if the reward value calculated for a certain candidate step size (e.g., 1 km) is higher than other increments (e.g., 0.5 km, 1.5 km), the model will determine it as the better candidate step size. The first model can output this better candidate step size as the next expansion step size. The first model can be a traditional AI model; it can also be a large AI model, for example, a large language model (LLM) or a multimodal large model.

[0037] S203, determine one or more verification dimensions based on the commuting-related housing search intention, and perform multi-level hierarchical verification on multiple candidate housings in sequence according to the priority order of each verification dimension. The multi-level hierarchical verification includes: determining whether the candidate housing meets the verification conditions of any verification dimension, and if the verification conditions are not met, determining whether the candidate housing meets the fault tolerance conditions corresponding to any verification dimension.

[0038] In this embodiment of the application, after screening out multiple candidate properties, the candidate properties can be verified in a multi-level hierarchical manner based on the verification dimension to ensure that the recommended properties meet the commuting requirements.

[0039] In the multi-level layered verification process, a verification mechanism involving verification, fault tolerance, and filtering is implemented for each verification dimension. For a candidate property, for any verification dimension, it is first determined whether the candidate property meets the verification conditions of the corresponding verification dimension in real time. If the verification conditions are met, it proceeds to the next level of verification (if there is only one verification dimension, it is added to the recommended property set). If the verification conditions are not met, it is further determined whether the candidate property meets the fault tolerance conditions. If the fault tolerance conditions are met, it proceeds to the next level of verification; if the fault tolerance conditions are not met, the candidate property is filtered out, and subsequent dimensions are no longer verified. In other words, candidate properties that do not meet either the verification conditions or the fault tolerance conditions are removed from the candidate set. The recommended property set is formed by combining all verification levels and candidate properties that fail verification but meet the fault tolerance conditions. Furthermore, properties can be output to the user based on the recommended property set, for example, by sorting multiple recommended properties according to continuous commuting satisfaction scores, and outputting a property recommendation list.

[0040] In this context, a verification dimension refers to a quantifiable or determinable attribute category used in the property recommendation process to measure whether candidate properties meet a user's commuting needs. Its specific value or status is compared with the verification conditions to determine whether the property passes the current level of verification—that is, from which aspect is the property verified to meet the requirements. The number of verification dimensions can be one or more, without limitation. Verification conditions and tolerance conditions are dynamically set based on the type of verification dimension. Verification conditions are hard threshold constraints, while tolerance conditions are soft boundaries that allow deviations from the verification conditions within a preset elastic range.

[0041] Fault tolerance conditions refer to a set of judgment rules used in multi-level layered verification processes to determine whether a candidate property's failure to pass real-time verification of a certain verification dimension is due to a misjudgment caused by temporary anomalies (such as traffic congestion or interface fluctuations). If a candidate property meets the fault tolerance conditions, it is still considered "verified" or "can be recommended as a fallback," avoiding the incorrect filtering of high-quality properties due to short-term data anomalies.

[0042] For example, the fault tolerance conditions may include: the historical verification data of the candidate property's corresponding verification dimension meets the verification conditions and / or a stability threshold. When a candidate property fails real-time verification on a certain verification dimension, the historical verification data of the community where the candidate property is located can be obtained, the mean and / or standard deviation of the historical verification data on that verification dimension can be calculated, and it can be determined whether the mean meets the verification conditions of that verification dimension, and / or whether the standard deviation of the historical data is less than a preset stability threshold. When one of the two conditions is met, the candidate property can be determined to meet the fault tolerance conditions and allowed to enter the recommended property set. When neither condition is met, the candidate property is determined not to meet the fault tolerance conditions and is removed.

[0043] For example, in the "commuting to find a house" category, commuting time is used as the verification dimension. If a user's requirement is a 30-minute commute by car, and the current commuting time of a candidate property is 35 minutes (exceeding the 30-minute threshold) after real-time verification, but the historical average of the candidate property over the past 30 days is 28 minutes (meeting the user's requirement) and the standard deviation is 4 minutes (less than the preset stability threshold), then it is considered an anomaly caused by temporary traffic congestion and is retained.

[0044] For example, if a candidate property has a real-time commute time of 45 minutes (exceeding the 30-minute threshold) and its historical average is 35 minutes (not meeting user needs), then the candidate property is determined not to meet the fault tolerance conditions and is removed from the candidate property set, no longer participating in subsequent processes.

[0045] For each subtype of commuting-related housing search intent, validation dimensions can consist of one or more housing search factors that are appropriate for the subtype. Specifically, validation dimensions can be determined based on explicit user needs (user input or settings), and can further be determined by combining implicit user preferences (historical behavior mining) and / or system-wide factors. For example, if a user inputs "hopes to get to Guomao within 30 minutes during the morning rush hour," validation dimensions could include commuting time and travel mode matching. As another example, for user profiles who frequently choose to commute by car, dimensions such as road distance and parking convenience could be added.

[0046] For general system factors, a mapping relationship between subtypes and house-finding factors can be pre-built. After identifying the subtype of commuting intention, house-finding factors suitable for that subtype are determined based on the mapping relationship as verification dimensions for subsequent multi-level hierarchical verification. For example, for location-based house-finding, verification dimensions may include the commuting distance from the property's latitude and longitude to the POI, as well as commuting time and walking accessibility. For nearby house-finding, verification dimensions may include the commuting distance between the property and the user's authorized location, as well as area radius coverage and surrounding facility density. For distance-based house-finding, verification dimensions may include the commuting distance from the property's latitude and longitude to the POI, as well as distance tolerance elasticity coefficient. For commuting-based house-finding, verification dimensions may include commuting time, commuting mode, and commuting stability. For administrative district / business district house-finding, verification dimensions may include consistency of administrative district or business district affiliation, as well as distance to the core POI of the administrative district or business district and regional living convenience. For finding a property by route, verification dimensions can include the commute time from the property to the nearest station, as well as the distance from the property to the specified transportation route, the number of transfers, and the frequency of service.

[0047] The verification conditions for these verification dimensions can be user-specified conditions, such as a commute time shorter than specified by the user, fewer subway transfers than specified by the user, a commute distance shorter than specified by the user, or a property's location perfectly matching the target area for intent recognition. If the user does not explicitly specify threshold conditions (such as time or distance thresholds), they can be inferred from information such as subtype, city attributes, and user profiles. For example, distance thresholds can be set based on city scale: 1.5-3km for first-tier cities and 2-5km for second-tier cities; based on location type: 2km for office buildings, 1km for schools, and 3km for commercial districts.

[0048] When there are multiple verification dimensions, multi-level hierarchical verification can be performed according to the priority order of the verification dimensions. The priority order can be a preset fixed order or a dynamically generated order determined by the scene-aware weight vector.

[0049] For example, a fixed order is used to filter listings across two dimensions. In the first-level verification dimension A, the commute time is verified to be ≤30 minutes. If the verification condition is met, the listing proceeds to the next level of verification; otherwise, it checks for tolerance conditions. If the tolerance conditions are met, the listing is marked as a tolerance listing and retained; otherwise, it is immediately filtered out and not verified further in subsequent dimensions. Next, in the second-level verification dimension B, subway coverage is verified, and the same verification, tolerance, and filtering mechanism is executed. Only listings that pass the first-level verification or meet the tolerance conditions will proceed to the second-level verification. If a candidate listing fails verification in verification dimension A but meets the tolerance conditions and also meets the verification or tolerance conditions in verification dimension B, or if a candidate listing passes verification in verification dimension A and also meets the verification or tolerance conditions in verification dimension B, the candidate listing can be added to the recommendation set.

[0050] The above-mentioned dynamic generation and determination of the scene-aware weight vector includes: acquiring historical user behavior data and calculating the objective weights of each verification dimension based on the historical user behavior data using the entropy weight method; acquiring spatiotemporal context information and dynamically adjusting the objective weights in combination with the spatiotemporal context information to generate a scene-aware weight vector; determining the priority order according to the order of the weights of each dimension in the scene-aware weight vector from high to low, and when performing multi-level hierarchical verification on candidate properties, prioritizing the verification of whether high-weight dimensions meet the verification conditions and fault tolerance conditions.

[0051] This process utilizes historical user behavior data (such as clicks, favorites, and transactions) and employs the EntropyWeight Method to mine information entropy for each validation dimension, thus assigning objective weights. The EntropyWeight Method assesses the discriminative power and importance of each dimension by measuring its information entropy within user behavior data: lower information entropy indicates greater differences in the dimension's value across different properties, resulting in a more significant impact on user decisions, and therefore assigning it a higher objective weight. This step ensures that weight calculations do not rely on subjective assumptions but rather extract the importance of dimensions from real user behavior.

[0052] Based on the objective weights obtained, spatiotemporal context information is introduced to dynamically adjust these weights. Specifically, through pre-defined context-dimension association rules or lightweight neural network modules, the system determines whether certain dimensions become more critical or less important in the current or upcoming commuting scenario of the user, based on the current or predicted spatiotemporal context (such as weather, time of day, and regional traffic conditions). The importance of relevant dimensions is then appropriately increased or decreased accordingly. For example, if user profiles indicate that a user frequently commutes during the morning rush hour, the weight of the commuting time dimension may be significantly increased.

[0053] The spatiotemporal context information refers to situational factors closely related to the user's future actual residence and commuting experience. These factors may include, but are not limited to, at least one of the following: time period type (including weekday morning and evening rush hours, off-peak hours, weekends, or public holidays), city type, season, long-term regional climate or geographical characteristics, or user preferences. This adjustment process generates a scenario-aware weight vector that retains the general patterns revealed by historical data while incorporating personalized sensitivity in the current context. The dynamic prioritization scheme allows the priority order of multi-level verification to align with the specific environment the user may face during a real commute. Without altering the user's fundamental intent, it intelligently determines which dimensions are more worthy of priority in the current or typical commuting context, thereby optimizing the recommendation strategy and making the recommendation results closer to real-life experiences, improving trust and conversion rates.

[0054] The generated scene-aware weight vectors are then sorted from highest to lowest value to determine the dynamic priority order of each verification dimension. When performing multi-level hierarchical verification on the candidate property set, the priority order of the verification dimensions is used to determine whether the candidate property meets the verification conditions or fault tolerance conditions of the current verification dimension.

[0055] For example, for a housing search category related to commuting, the validation dimensions include commuting time, surrounding environment, and subway distance. Based on user behavior logs for this category over the past year, the variances of commuting time, surrounding environment, and walking time are calculated, and the objective weights obtained using the entropy weighting method are 0.6, 0.25, and 0.15, respectively. When a user's history shows or explicitly expresses a desire to minimize walking, the weight of walking time is increased, and the weight of the surrounding environment is decreased, ultimately generating a scene-aware weight vector of [0.6, 0.1, 0.3]. During validation, commuting time is validated first to determine if the validation and fault tolerance conditions are met; then walking time is validated, and finally the surrounding environment is validated.

[0056] In this embodiment, the entropy weight method is fused with spatiotemporal context to generate a scene-aware weight vector, thereby achieving a balance between the objectivity and context adaptability of the verification dimension weights. This can adapt to complex scenarios and change the multi-level hierarchical verification from a fixed order to on-demand sorting, avoiding ineffective calculations of low-weight factors and achieving more efficient verification decisions that better meet user needs, thus improving verification efficiency and recommendation relevance.

[0057] Optionally, the aforementioned historical verification data can be grouped and managed according to city attributes and / or time period types. Obtaining historical verification data for candidate properties includes: determining the current city attributes and / or commuting time period type based on the user's input housing search requirements; and obtaining historical verification data that matches the current city attributes and / or commuting time period type.

[0058] The city attributes include city tier, level of transportation infrastructure, and dominant commuting patterns, while the time period types include weekday morning rush hour, weekday evening rush hour, off-peak hours, weekends, and holidays. Data varies significantly across different cities and time periods, and different historical datasets may perform differently on the same validation dimension, leading to varying fault tolerance decisions. Therefore, when implementing fault tolerance, it is crucial to acquire historical validation data matching the city attributes and time period types relevant to the housing search needs. This allows for refined fault tolerance control based on both city differences and time context, improving the accuracy of recommendation results.

[0059] Furthermore, reasonable thresholds for some validation dimensions can be set differently based on city attributes. For example, for properties in Chengdu, a standard deviation of historical commuting time of less than 8 minutes is considered stable; while for similar properties in Beijing, due to greater traffic fluctuations, the standard deviation threshold can be relaxed to 12 minutes.

[0060] Furthermore, after each recommendation is completed, the relevant data is saved. Then, the saved data can be aggregated at regular intervals to train offline on data of different cities and time periods, generating historical validation data. The relevant data may include, but is not limited to: search intent, the subtype corresponding to the search intent, the corresponding city, the time period, the output neighborhoods and properties, real-time calculated commuting time / distance, and the latitude and longitude of the target location, etc.

[0061] S204 adds candidate properties that meet the verification conditions of each verification dimension, as well as candidate properties that do not meet the verification conditions of some verification dimensions but meet the corresponding fault tolerance conditions, to the recommended property set.

[0062] Optionally, after constructing the recommended housing set, the following can also be done: count the number of housing sets that meet the verification conditions in the recommended housing set; if the number is lower than a preset threshold, relax the fault tolerance conditions of at least one verification dimension, and re-perform multi-level hierarchical verification on the original candidate housing set to expand the recommended housing set.

[0063] S205 outputs recommendation results to users based on the recommended housing list set.

[0064] Optionally, after obtaining the recommended housing set, the continuous commuting satisfaction score for each candidate housing in the recommended housing set can be calculated; for candidate housing that does not meet the verification conditions of some verification dimensions but meets the corresponding fault tolerance conditions, the continuous commuting satisfaction score is reduced in weight; the continuous commuting satisfaction score of each candidate housing is used as the core feature, and together with the auxiliary features related to the subtype, it is input into the learning ranking model; the learning ranking model performs a comprehensive ranking of the recommended housing set and outputs the ranking result.

[0065] Among them, the Commute Satisfaction Score (CSS) is a continuous numerical indicator that quantifies the degree to which candidate properties meet users' commuting needs, reflecting the extent to which properties satisfy users' commuting requirements.

[0066] The Learning-to-Rank (LTR) model uses CSS and other auxiliary features as input features and optimizes the ranking results through supervised learning. It performs a global comprehensive ranking of candidate properties to make the ranking results as close as possible to users' historical preferences or business goals (such as maximizing conversion rates).

[0067] When sorting, candidate properties that pass multi-level layered verification are divided into two categories: the first category is those that meet the verification conditions in all verification dimensions (i.e., pass the verification); the second category is those that do not meet the verification conditions in at least one dimension, but meet the fault tolerance conditions of the corresponding dimension (i.e., fail the verification but meet the fault tolerance). Although these properties fail the current verification due to temporary traffic congestion, accidents or interface errors, their long-term commuting performance is reliable and they have recommendation value.

[0068] Commute Satisfaction Score (CSS) is calculated for both types of properties. A complete feature vector is constructed for each property, including the CSS and other auxiliary features. For the second type of property, the CSS is weighted down. For example, a comprehensive weighting coefficient can be calculated based on the number of validation dimensions that the candidate property does not satisfy and their corresponding weights; the continuous commuting satisfaction score is multiplied by the comprehensive weighting coefficient to obtain the weighted score; the weighted score is used as the CSS input for the candidate property in the learning and ranking model.

[0069] The feature vectors of each property are input into a trained LTR model, which outputs a comprehensive ranking score for each property. The properties are then sorted from highest to lowest score to generate a recommended property ranking result. In this embodiment, for verified properties, a continuous commuting satisfaction score is calculated and used as a core feature input into the ranking model for comprehensive ranking. Properties that do not meet the verification criteria but meet the fault tolerance criteria are recommended with reduced weight. Properties are not eliminated during the ranking stage; only the display order is adjusted. This differentiates between fully verified properties and fault-tolerant properties, preserving potentially acceptable options while maintaining a clear hierarchy in the recommendation results, prioritizing properties that better match the user's commuting intentions and improving property conversion rates.

[0070] Optionally, based on the LTR output, the second category of properties can be further explicitly de-weighted (e.g., by multiplying the LTR score by a coefficient less than 1), so that their final ranking is lower than that of the first category of properties with the same LTR score. The de-weighting magnitude can be dynamically adjusted based on the number and severity of the dimensions that are not met, or the margin of error tolerance threshold.

[0071] The calculation methods for continuous commuting satisfaction scores differ across different subtypes. For example, for location-based, nearby, or distance-based house searches, the CSS (Commuting Satisfaction Score) can be obtained by applying a decay function mapping based on the distance from the property to the target location or commuting time. For commuting-based house searches, continuous scores can be generated based on historical commuting times for different time periods and user-specified durations. In district / business area house searches, which implicitly involve commuting intent, the target area can be treated as a set of Points of Interest (POIs) (such as all office buildings within a business area). The commuting time from the property to the nearest POI or a weighted average POI is calculated, and the CSS is calculated using the commuting-based house search method. For route-based house searches, scores can be calculated based on the walking distance and walking time from the property to a specified transportation route.

[0072] Auxiliary features are a set of structured feature vectors, excluding continuous commuting satisfaction scores, adapted to the subtype and used to characterize the comprehensive attributes of candidate properties. Different commuting-related house-hunting types correspond to different user decision-making logics. By introducing auxiliary features strongly correlated with the subtype, the learning ranking model can identify and respond to ranking preferences in different scenarios, improving the relevance of recommendation results and user conversion rates. Auxiliary features can be differentiated based on the semantic features of the subtype and differences in user intent, specifically including at least one of the following types of features: Spatial location features: such as the straight-line distance, road distance, and estimated walking / cycling / driving time between the candidate property and the target location; Regional attribute features: such as the administrative district, business district, whether it is located along a subway line, whether it is in a key school district, and the surrounding density; Property ontology features: such as house price, area, unit type, floor, orientation, decoration level, building year, and whether it has an elevator; Subtype-adaptive features: features customized for different house-hunting types. Appropriate auxiliary features can be selected from these features.

[0073] For example, in subtype-specific matching features, for nearby housing search, auxiliary features may include regional population density, number of commercial facilities, and nighttime light index. For location-based housing search, auxiliary features may include route detour, estimated walking time, estimated cycling time, estimated driving time, and estimated public transportation time. For distance-based housing search, auxiliary features may include road congestion index, traffic restriction policies, and parking convenience. For commuting housing search, auxiliary features may include commuting stability, transportation mode preference matching degree, and first and last bus times. For administrative district / business district housing search, auxiliary features may include median rent, school district grade, and safety rating. For route-based housing search, auxiliary features may include service frequency, transfer convenience, station congestion, and future expansion potential of the route plan.

[0074] The following example illustrates the housing recommendation method provided in this application. A user inputs "a house 30 minutes from xx company." Through intent parsing, the intent corresponding to the user's housing search request is identified as a commuting-related housing search intent and specifically a commuting-related housing search type. The verification dimensions are determined to include commuting time, commuting stability, and commuting mode matching degree. Based on historical user behavior data, the objective weights for commuting time, commuting stability, and commuting mode matching degree are calculated to be 50%, 30%, and 20%, respectively. Through dynamic adjustment, scene-aware weight vectors are generated as follows: 40%, 25%, and 35%. Then, multi-level layered verification is performed according to priority: First, for commuting time, real-time verification or fault-tolerant verification is performed to ensure that the real-time calculated commuting time and the historical average commuting time do not exceed 30 minutes; second, for commuting stability, it is verified whether the current commuting mode (e.g., accessible by subway) is supported or whether the user's preferred commuting mode has been supported historically; finally, for commuting stability, it is checked whether the current real-time deviation is less than 5 minutes or whether the historical commuting time standard deviation is less than 5 minutes (reflecting reliability). The system iterates through multiple candidate listings, calculates CSS scores for listings that pass multi-level stratification, and introduces auxiliary features such as congestion index and first and last bus times. The CSS scores and auxiliary features are then input into the LTR model to obtain the ranking results. Recommended listings are then output to the user according to the ranking results.

[0075] Optionally, after providing recommended properties to users, feedback-driven dynamic optimization can be performed, including the following steps: collecting explicit or implicit user feedback on the recommendation results, where explicit feedback includes user evaluations of their actual commuting experience or authorized access to real commuting trajectory data, and implicit feedback includes user behavior in response to the recommendation results; comparing the explicit or implicit feedback with continuous commuting satisfaction scores to identify overestimated or underestimated samples; generating calibration coefficients based on multi-dimensional aggregated bias data based on the overestimated or underestimated samples, and dynamically correcting the continuous commuting satisfaction scores using the calibration coefficients.

[0076] Implicit feedback includes positive user behaviors such as clicking on recommended listings, saving them, initiating viewings, and dwell time on pages, as well as negative signals such as swiping to skip, quickly returning, and closing without interaction. Explicit feedback includes: obtaining subjective evaluations of the user's commuting experience through a lightweight questionnaire after the user completes a viewing or signs a contract (such as "whether the actual commuting time meets expectations"), or, with the user's authorization, automatically collecting their actual commuting trajectory from the listing to the target POI over several consecutive workdays through location data, and calculating actual commuting performance metrics based on this.

[0077] The user feedback is compared with the commuting satisfaction score (CSS) generated during recommendation. If the feedback is inconsistent with the original CSS, it needs to be corrected. For example, if the user feedback is "does not meet the requirements" but the original CSS is ≥0.8, it is determined that the CSS is overestimated; if the user feedback is "meets the requirements" but the original CSS is ≤0.3, it is determined that the CSS is underestimated, thus obtaining overestimated or underestimated samples.

[0078] Based on overestimated or underestimated samples, bias data is aggregated across multiple dimensions such as target location, region, route, or time period to generate CSS calibration coefficients and construct a dynamically corrected mapping table. For example, "Properties near station xx on Metro Line 2 should have their CSS multiplied by a calibration coefficient of 0.85 during the morning rush hour." This coefficient is updated periodically and used for subsequent CSS calculations.

[0079] Furthermore, the LTR model can be incrementally learned online based on overestimated or underestimated samples. For example, overestimated or underestimated samples can be transformed into positive / negative training samples (positive samples: feedback matches and transformation occurs; negative samples: feedback does not match or are quickly skipped), added to the online training queue of the ranking model, and incrementally updated using an online learning algorithm to ensure the ranking logic continuously reflects users' true preferences. For fallback properties that enter the recommended property set due to meeting the fault tolerance condition, if they receive positive feedback, their ranking weight will be increased or their deweighting coefficient decreased in subsequent recommendations.

[0080] In summary, this application provides a housing recommendation method. By identifying commuting-related housing search intentions, it constructs one or more verification dimensions to match them, and performs verification on candidate housing listings based on these dimensions. This effectively filters out housing listings that are clearly inconsistent with the user's commuting needs, thereby ensuring that the recommendation results are more in line with the user's true intentions and significantly improving recommendation accuracy. Furthermore, the method provided in this application adopts a multi-level hierarchical verification mechanism, performing judgments sequentially according to the priority order of each verification dimension. This ensures that verification dimensions that deserve priority are verified first, while secondary verification dimensions are subsequently verified. This makes the verification logic hierarchical and efficient, allowing for faster elimination of obviously mismatched housing listings, reducing invalid calculations, and ensuring that core needs are met first, thus improving the overall recommendation quality. Furthermore, the method provided in this application introduces fault tolerance conditions. Even if a candidate property does not meet the strict verification conditions of a certain verification dimension, it can still be retained in the recommendation set according to the preset reasonable fault tolerance conditions. This avoids the problem of properties not being recommended due to a single hard rule, and takes into account both the rigor and flexibility of the recommendation. It avoids the misscreening of high-quality potential properties and expands the effective recommendation range, significantly improving user satisfaction and the exposure and conversion efficiency of platform properties.

[0081] Furthermore, in prioritizing, the entropy weight method based on historical behavior is used to objectively quantify the true importance of each verification dimension in user decision-making. On this basis, spatiotemporal context information is introduced to dynamically adjust the weights, so that the priority of the verification dimensions can adapt to the scene. This improves the system's ability to perceive and respond to complex real-world environments, making the recommendation results closer to real-life experiences and increasing trust and conversion rates.

[0082] Based on this, fully verified listings and those with tolerance for errors are treated differently. Listings that better match the user's commuting intentions are displayed first, which retains potentially acceptable options while maintaining a clear hierarchy in the recommendation results, thereby improving the listing conversion rate.

[0083] In summary, the embodiments of this application, by integrating precise intent recognition, multi-level verification driven by dynamic weights, quantified ranking of commuting commuting satisfaction, and closed-loop optimization based on user feedback, can effectively solve problems such as not recommending available properties or inaccurate property recommendations in commuting-related housing search scenarios. This significantly improves the coverage, accuracy, personalization level, and user experience of recommendation results, thereby reducing user churn and increasing effective conversion rates.

[0084] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 101 to 105 can be device A; or the execution subject of step 101 can be device A, and the execution subject of steps 102 to 105 can be device B; and so on.

[0085] In some of the processes described in the above embodiments and accompanying drawings, multiple operations are included that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the terms "first," "second," etc., used herein are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0086] Figure 3 This is a schematic diagram of a housing recommendation device provided in an embodiment of this application. Figure 3 As shown, the device includes: an intent parsing module 301, a filtering module 302, a verification module 303, and a recommendation module 304. The intent parsing module 301 is used to receive the user's housing search requirements and perform intent parsing on the housing search requirements, identifying the intent corresponding to the housing search requirements as a commuting-related housing search intent.

[0087] The filtering module 302 is used to filter multiple candidate properties from the platform's property database based on the intent to find a house for commuting purposes.

[0088] The verification module 303 is used to determine one or more verification dimensions based on the commuting-type house-finding intent, and to perform multi-level hierarchical verification on multiple candidate properties in sequence according to the priority order of each verification dimension. The multi-level hierarchical verification includes: determining whether the candidate property meets the verification conditions of any verification dimension, and if the verification conditions are not met, determining whether the fault tolerance conditions corresponding to any verification dimension are met.

[0089] The recommendation module 304 is used to add candidate properties that meet the verification conditions of each verification dimension, as well as candidate properties that do not meet the verification conditions of some verification dimensions but meet the corresponding fault tolerance conditions, to the recommended property set; and output recommendation results to the user based on the recommended property set.

[0090] 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.

[0091] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device includes a memory 41 and a processor 42.

[0092] Memory 41 is used to store computer programs and can be configured to store various other data to support operation on the computing platform. Examples of this data include instructions for any application or method operating on the computing platform, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0093] The processor 42, coupled to the memory 41, executes the computer program in the memory 41 to perform the following: receiving a user's housing search request and parsing the request to identify it as a commuting-related housing search intent; filtering multiple candidate properties from the platform's property database based on the commuting-related housing search intent; determining one or more verification dimensions based on the commuting-related housing search intent and performing multi-level hierarchical verification on the multiple candidate properties according to the priority order of each verification dimension, wherein the multi-level hierarchical verification includes: determining whether a candidate property meets the verification conditions of any verification dimension, and if not, determining whether it meets the fault tolerance conditions corresponding to any verification dimension; adding candidate properties that meet the verification conditions of each verification dimension, as well as candidate properties that do not meet the verification conditions of some verification dimensions but meet the corresponding fault tolerance conditions, to a recommended property set; and outputting recommendation results to the user based on the recommended property set.

[0094] 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.

[0095] Furthermore, such as Figure 4 As shown, the electronic device also includes other components such as a communication component 43, a display 44, a power supply component 45, and an audio component 46. Figure 4 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 4 The components shown. Additionally... Figure 4 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the work node. In this embodiment, the work node 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 work node in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 4 The components within the dashed box; if the working node in this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may be omitted. Figure 4 The component within the dashed box.

[0096] 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.

[0097] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable 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), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), 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-transmission medium.

[0102] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0103] 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.

[0104] 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 recommending a house, characterized by, The method comprises: receiving a user inputted house searching demand, and performing intent analysis on the house searching demand to identify that the house searching demand corresponds to a commuting type house searching intent; filtering a plurality of candidate house sources from a platform house source library based on the commuting type house searching intent; determining one or more verification dimensions based on the commuting type house searching intent, and sequentially performing multi-level layered verification on the plurality of candidate house sources according to a priority order of each verification dimension, wherein the multi-level layered verification comprises: judging whether the candidate house source meets a verification condition of any verification dimension, and judging whether the candidate house source meets a fault tolerance condition corresponding to the any verification dimension in a case where the candidate house source does not meet the verification condition; adding the candidate house source meeting the verification condition of each verification dimension and the candidate house source not meeting the verification condition of part of the verification dimensions but meeting the corresponding fault tolerance condition into a recommended house source set; outputting a recommendation result to the user based on the recommended house source set. 2.The method of Claim 1, wherein, The priority order is a fixed order, or is determined according to the following steps: obtaining historical user behavior data, and calculating objective weights of each verification dimension based on the historical user behavior data by using an entropy weight method; obtaining spatio-temporal context information, and dynamically adjusting the objective weights to generate a scenario awareness weight vector based on the spatio-temporal context information; determining the priority order according to an order of each dimension weight in the scenario awareness weight vector from high to low.

3. The method of claim 1, wherein, The determination of the one or more verification dimensions based on the commuting type house searching intent comprises: determining a sub-type corresponding to the commuting type house searching intent, the sub-type comprising any one of a point house searching, a nearby house searching, a distance house searching, a commuting house searching, an administrative district / commercial circle house searching or a line house searching; dynamically configuring the verification dimensions according to the sub-type corresponding to the commuting type house searching intent.

4. The method of claim 1, wherein, The judgment of whether the candidate house source meets the fault tolerance condition corresponding to the any verification dimension comprises: obtaining historical verification data of the candidate house source; calculating a mean value and / or a standard deviation of the historical verification data in the any verification dimension; in a case where the mean value meets a verification condition, and / or in a case where the standard deviation is less than a preset stability threshold, the candidate house source meets the fault tolerance condition corresponding to the any verification dimension.

5. The method of claim 4, wherein, The historical verification data is grouped and managed according to city attributes and / or time period types, and the obtaining of the historical verification data of the candidate house source comprises: determining a current city attribute and / or a commuting time period type based on the user inputted house searching demand; obtaining historical verification data matching the current city attribute and / or the commuting time period type.

6. The method according to any one of claims 1 to 5, characterized in that, The method further comprises: when the candidate house source does not meet the verification condition and does not meet the fault tolerance condition in the any verification dimension, terminating subsequent verification of the candidate house source, and excluding the candidate house source from the recommended house source set.

7. The method of claim 1, wherein, After obtaining the recommended house source set, the method further comprises: calculating a commuting satisfaction degree continuous score corresponding to each candidate house source in the recommended house source set; The candidate house that does not meet the verification condition of the part but meets the corresponding fault-tolerant condition is subjected to weight reduction processing on the basis of the continuous score of the commuting satisfaction degree; The continuous score of the commuting satisfaction degree of each candidate house is input into a learning ranking model as a core feature together with auxiliary features related to the subtypes; The learning ranking model outputs a ranking result after comprehensively ranking the recommended house set.

8. The method of claim 7, wherein, After outputting the recommended house to the user, further comprising: Collecting explicit feedback or implicit feedback of the user on the recommended result, the explicit feedback including the user's evaluation of the actual commuting experience or the authorized real commuting trajectory data, and the implicit feedback including the user's behavior for the recommended result; Comparing the explicit feedback or implicit feedback with the continuous score of the commuting satisfaction degree to identify overestimation samples or underestimation samples of the continuous score of the commuting satisfaction degree; Based on the overestimation samples or underestimation samples of the continuous score of the commuting satisfaction degree, a calibration coefficient is generated based on multi-dimensional aggregated bias data, and the continuous score of the commuting satisfaction degree is dynamically corrected using the calibration coefficient.

9. An electronic device, comprising: It includes: A memory, a processor; wherein the memory has executable code stored thereon, and when the executable code is executed by the processor, the processor executes the method of any one of claims 1-8.

10. A non-transitory machine-readable storage medium, comprising: The non-transitory machine-readable storage medium has executable code stored thereon, and when the executable code is executed by the processor of the electronic device, the processor executes the method of any one of claims 1-8.

Images