Information processing method and device, storage medium and program product

Abstract

The embodiment of the invention provides an information processing method and device, a storage medium and a program product. According to the scheme, the housing resource release and housing resource leasing process is promoted to a branch link mapping layer of staged intention recognition from traditional form filling through a unified service interface; using the first large model to complete initial intention recognition so as to determine a target branch link; then fine intention recognition is carried out based on an attention mechanism so as to determine a target service type on a target branch link, and progressive intention recognition from coarse granularity to fine granularity and progressive decision from macroscopic intention to microscopic service type are completed; and finally, calling a target model adaptive to the target service type to generate a slot template adaptive to the target service type, and executing a corresponding target operation. According to the unified architecture, the architecture complexity and the process complexity are remarkably reduced, flexible expansion of service types is supported, one-key house resource release or one-key house resource search can be achieved, and good use experience is brought to users.

Description

Technical Field

[0001] This application relates to the field of computer processing technology, and in particular to an information processing method, device, storage medium and program product. Background Technology

[0002] With the widespread use of online property listing platforms, their functions are becoming increasingly diverse. Users have two main needs on these platforms: finding properties and posting listings. To meet these needs, property listing platforms provide separate entry points and forms for each. Users can access the property search page through the property search entry point to find properties, or they can access the property posting page through the property posting entry point to post a property. For the separate forms, the property search page requires users to select city → region → neighborhood → price → apartment type step by step, while the posting page requires users to repeatedly fill in city → neighborhood → area → price → photo.

[0003] However, the aforementioned interfaces are highly complex, have lengthy workflows, and involve overlapping components. For fields such as city, neighborhood, and price, separate sets of interactive components are maintained for both the search and posting of listings, resulting in high code duplication and requiring modifications on both fronts during updates, leading to significant maintenance costs. Furthermore, different users have different needs when searching for or posting listings, and even the same user's needs may change continuously. Consequently, the forms need constant adaptive updates. For example, when a user adds requests such as "search by subway" or "post by school," new forms need to be added to both sides, further increasing maintenance costs.

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

[0005] This application provides an information processing method, device, storage medium, and program product that eliminates the technical problems of architectural redundancy, component duplication, high maintenance costs, and complex processes caused by traditional platforms maintaining separate housing listing and rental entry points. It supports flexible expansion of service types and significantly reduces architectural and process complexity, providing users with a better user experience.

[0006] This application provides an information processing method, comprising: responding to an input operation in a target service interface provided on a service page, obtaining user-inputted demand information, wherein the target service interface is a unified entry point for users to publish or rent properties; using a first major model to perform initial intent recognition on the demand information, obtaining the user's initial intent and the target branch link corresponding to the initial intent, wherein the initial intent includes a property rental intent and / or a property publishing intent, and the property rental intent and the property publishing intent correspond to different branch links, each branch link including multiple service types and a second major model adapted to each service type, the service types on different branch links being different; based on an attention mechanism, combining the demand information and the target branch link to perform refined intent recognition, obtaining the user's refined intent; based on the refined intent, determining the target service type on the target branch link, and using the second major model adapted to the target service type on the target branch link as the target major model; calling the target major model to generate a key information slot template adapted to the target service type; and based on the key information slot template, executing the target operation corresponding to the refined intent to obtain the operation result.

[0007] This application also 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.

[0008] This application also 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.

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

[0010] In this embodiment, a unified service interface elevates the property listing and rental process from traditional form filling to a branch-link mapping level based on intent recognition, employing a phased, progressive intent recognition approach. Specifically, firstly, an initial intent recognition is performed based on demand information using a primary model, mapping natural language to the target branch link corresponding to property rental or listing. Then, a refined intent recognition is performed based on an attention mechanism to determine the target service type on the target branch link, completing a progressive intent recognition process from coarse-grained to fine-grained, and a progressive decision-making process from macro-intent to micro-service type. This unified architecture eliminates the redundancy, component duplication, and high maintenance costs caused by traditional platforms maintaining separate property listing and rental entry points, significantly reducing structural complexity. Furthermore, the phased intent recognition mechanism, executed progressively within the same primary model, avoids the accuracy decay caused by multi-model cascading, improving the accuracy of intent recognition and thus the accuracy of determining the target service type. Finally, the second major model on the target branch link that is compatible with the target service type is taken as the target major model, and the target major model is called to generate a slot template that is compatible with the target service type and execute the corresponding target operation (property listing or property search). This not only supports the flexible expansion of service types, but also enables one-click property listing or one-click property search, bringing a good user experience. Attached Figure Description

[0011] 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 A flowchart illustrating an information processing method provided for an exemplary embodiment of this application; Figure 2 A flowchart illustrating an initial intent recognition method provided for an exemplary embodiment of this application; Figure 3 A flowchart illustrating a refined intent recognition method provided for an exemplary embodiment of this application; Figure 4 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Detailed Implementation

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

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

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

[0015] Following the aforementioned background technology, and addressing the technical problems existing in the background technology, this application embodiment elevates the property listing and rental process from traditional form filling to the branch link mapping level of intent recognition through a unified service interface, and it is a phased progressive intent recognition. Specifically, firstly, the first large model completes initial intent recognition based on demand information, thereby mapping natural language to the target branch link corresponding to property rental or property listing. Then, based on an attention mechanism, refined intent recognition is performed to determine the target service type on the target branch link, completing a progressive intent recognition from coarse to fine granular, and a progressive decision from macro intent to micro service type. This unified architecture eliminates the problems of architectural redundancy, component duplication, and high maintenance costs caused by traditional platforms maintaining separate property listing and rental entry points, significantly reducing structural complexity. In addition, the phased intent recognition mechanism, which is executed progressively within the same large model, avoids the accuracy decay caused by multi-model cascading, improves the accuracy of intent recognition, and thus improves the accuracy of determining the target service type. Finally, the second major model on the target branch link that is compatible with the target service type is taken as the target major model, and the target major model is called to generate a slot template that is compatible with the target service type and execute the corresponding target operation (property listing or property search). This not only supports the flexible expansion of service types, but also enables one-click property listing or one-click property search, bringing a good user experience.

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

[0017] Figure 1 This is a flowchart illustrating an exemplary embodiment of the information processing method provided in this application. Figure 1 As shown, the method includes: 101. Respond to the input operation in the target service interface provided on the service page, and obtain the user's input request information. The target service interface is a unified entry point for users to publish or rent out properties. 102. Use the first major model to identify the initial intent of the demand information, and obtain the user's initial intent and the target branch link corresponding to the initial intent. The initial intent includes the intent to rent a property and / or the intent to publish a property. The intent to rent a property and the intent to publish a property correspond to different branch links. Each branch link includes multiple service types and the second major model adapted to each service type. The service types on different branch links are different. 103. Based on the attention mechanism, combined with demand information and target branch links, refined intent recognition is performed to obtain the user's refined intent; 104. Based on the refined intent, determine the target service type on the target branch link, and take the second largest model on the target branch link that matches the target service type as the target large model; 105. Call the target large model to generate key information slot templates that match the target service type; 106. Based on the key information slot template, execute the target operation corresponding to the refined intent to obtain the operation result.

[0018] In real life, people often have needs for renting and listing properties. To address this, property listing platforms can provide both rental and listing functions through their service pages. The rental function essentially functions as a property search, allowing users to select a property that matches their needs from the search results. To improve service efficiency and user experience, the rental and listing functions can be integrated into a unified service portal. This allows users to both rent and list properties through this single portal, simplifying the service interface and providing a unified experience.

[0019] In this embodiment, the service page of the housing platform provides a target service interface, where users can input their requirements. The target service interface serves as a unified entry point for users to perform operations such as renting or posting housing listings. However, the functionality of this target service interface is not limited to renting and posting housing listings; it can be expanded according to the user's actual needs, for example, by adding vehicle rental or vehicle posting functions. This embodiment does not impose such limitations.

[0020] Accordingly, in step 101, the system can respond to input operations in the target service interface provided on the service page and obtain the user's input requirement information. Requirement information refers to monomodal or multimodal information describing the user's needs, encompassing text, images, voice, and / or audio-visual information, etc., and the content of the requirement information will vary depending on the user's needs. For example, when the user's need is for listing a property, the requirement information may include specific property information and the user's requirements for listing, such as "Renting a fully furnished two-bedroom apartment in a community 3 kilometers from ** subway station, pets allowed, rent approximately 5000 yuan, negotiable, etc.," as well as interior photos; when the user's need is for renting a property, the requirement information may be such as "Renting a two-bedroom apartment 3 kilometers from ** subway station, pets allowed, commute time not exceeding 1 hour." Regardless of the type of user need, it should include a relevant description representing their actual purpose, such as "property rental" or "property listing," to facilitate subsequent differentiation of user need types based on actual purpose. If the user's input does not include information representing their actual purpose, a prompt message can be sent to the user through pop-up windows or other means. The prompt message could be something like, "Please enter your actual purpose. Do you want to post a listing or rent a property?", but it is not limited to this.

[0021] This embodiment does not limit the implementation method for obtaining user input request information in response to input operations in the target service interface provided on the service page. For example, the target service entry can be displayed on the service page in the form of an interactive entry card, with an information input icon on the entry card; in response to a trigger operation on the input icon, a text input box, a voice input box, and / or an audio / video input box can be presented; in response to an input operation on any input box, the corresponding request information is entered, and the property platform can obtain the request information. As another example, the target service entry can be displayed on the service page in the form of an interactive entry card; in response to a trigger operation on the target service entry, the user enters the target service page, which contains at least one information configuration item, such as a text information configuration item, an image information configuration item, a voice information configuration item, and / or an audio information configuration item; in response to a configuration operation on any configuration item, the corresponding request information can be obtained. For example, the target service entry point can be displayed on the service page in the form of an interactive entry card; in response to a trigger operation on the target service entry point, a floating configuration card can be displayed, containing at least one information configuration item, such as text information configuration item, image information configuration item, voice information configuration item, and / or audio information configuration item; in response to a configuration operation on any configuration item, the corresponding requirement information can be obtained. However, the above content is only an example and does not constitute a limitation on the technical solution of this application.

[0022] In this embodiment, user demand represents the user's intent, and the subsequent processing flow is different when the user's intent is different. So after obtaining the user's demand information, referring to step 102, the first large model can be used to identify the initial intent of the demand information to obtain the user's initial intent and its corresponding target branch link. The initial intent includes the intent to rent a property and / or the intent to post a property. Different initial intents correspond to different branch links. Each branch link includes multiple service types and their corresponding large models. The service types on different branch links are different. For example, when the initial intent is to rent out a property, the service types on the corresponding target service link (i.e., the property rental service link) include, but are not limited to: renting out properties by neighborhood (finding or renting a property), renting out properties by subway / station, renting out properties by school (school district properties), renting out properties by office building / park, renting out properties by business district, renting out properties by landmark / point of interest (POI) (POI refers to a geographical entity with specific significance, such as a subway station, shopping mall, school, etc., and the attribute field is coordinates), renting out properties by budget range, renting out properties by apartment type / area, renting out properties by decoration standard, or renting out properties by shared / entire rental type. For example, when the initial intent is to post property listings, the service types on the corresponding target service chain include, but are not limited to: posting property listings by neighborhood, by price range, by new property type, by resale property type, by whole / shared rental type, by decoration standard, by property ownership term, by floor / elevator type, by commercial / residential property type, and by short-term / long-term rental type. In other words, each branch link includes multiple service nodes and their corresponding larger models. Different nodes on the same branch link are independent and do not affect each other. Different nodes correspond to different service types, and the nodes on different branch links are different. It should be noted that a user's request can include one or more service types. Taking the intent to post property listings as an example, property listings can be posted by neighborhood and by price range simultaneously. Correspondingly, the corresponding models can be called to post property listings by neighborhood and by price range respectively. Furthermore, the first major model can be a large AI model. A large AI model refers to a model whose parameters meet the set parameter quantity requirements. This embodiment does not limit the parameter quantity requirements, and different definitions may exist in different scenarios and fields. For example, in the scenario of property listing or property rental, a large AI model can refer to a model with a parameter scale of tens of billions, hundreds of billions, or even trillions. However, this definition of the model parameter quantity is only an example and does not constitute a limitation on this application. This embodiment also does not limit the type of large AI model, such as a large language model (LLM), PaLM, or LLaMA.In addition, for the relevant descriptions of the major models corresponding to each service type, please refer to the relevant descriptions of the first major model mentioned above, which will not be repeated here.

[0023] It is important to note that user demand information can contain one or more initial intents. For example, a user may own property but intend to rent it out and rent another property for the same purpose, such as for their child's schooling or their own work. In this case, the user can simultaneously input their rental and listing needs through a unified target service entry point. This unified entry point can simultaneously identify the user's rental and listing intents, and then execute the subsequent rental and listing processes in parallel through the branch links corresponding to the rental and listing intents. This solution allows users to input multiple needs at once (such as renting out their own property and renting another property in a good school district). It simultaneously achieves parallel recognition of multiple initial intents within the same target service interface and executes subsequent processes in parallel through two branch links. This capability not only simplifies the user's operation path and avoids repeatedly inputting redundant fields such as city and neighborhood, but also significantly improves operational efficiency. More importantly, the system architecture supports multi-intent session caching isolation and parallel task scheduling, providing native support for complex scenarios such as "property swaps," enhancing the breadth and flexibility of the housing platform in meeting real user needs.

[0024] After obtaining the user's initial intent and its corresponding target branch link, refer to step 103. Based on the attention mechanism, refined intent recognition can be performed by combining demand information and the target branch link to obtain the user's refined intent. The attention mechanism is a weighted summation and fusion mechanism based on query vectors, key vectors, and value vectors, used to calculate the importance weight of each element in the input sequence for the current prediction task. In this scheme, the attention mechanism specifically refers to using the user's input demand information as the query vector, and the embedding vectors of each service type on the target branch link as the key and value vectors. An attention weight vector is obtained by scaling the dot product, such as a one-dimensional attention weight vector. Each element of this attention weight vector represents the semantic matching degree between the demand information and the corresponding service type. The semantic matching degree refers to the normalized relevance score between the demand information and each sub-service type in the joint vector space, obtained through scaling the dot product operation. Its value ranges from zero to one, representing the semantic fit between the user's input text and each service type (such as "renting houses by neighborhood (find a house)", "renting houses by subway", "posting houses by price", etc.). Correspondingly, refined intent refers to the micro-level service direction that best matches the user's actual needs, identified from multiple service types in the current branch link, using an attention mechanism, given that the initial intent (housing rental intent or housing listing intent) has been determined. Its granularity is below the initial intent but above specific database query fields, serving as a progressive decision node connecting macro-level intent and micro-level slot templates. Refined intent is matched with service type, or the refined intent itself is the service type; once the refined intent is obtained, the target service type can be determined.

[0025] After obtaining the refined intent, referring to step 104, the target service type on the target branch link can be determined according to the refined intent, and the second major model on the target branch link that matches the target service type is taken as the target major model. Then, referring to step 105, the target major model is invoked to generate a key information slot template that matches the target service type.

[0026] It's important to note that the key information slot templates differ for different target branch links. These target branch links include those for listing rental intent and those for listing posting intent. The key information slot template for the listing rental intent branch link is used for listing rental (search) and generates structured listing rental parameters for retrieval, which are then converted into search queries. These structured listing rental parameters do not include the display location and format of key information after listing. Conversely, the key information slot template for the listing posting intent branch link is used for listing posting. This template generates structured listing posting parameters and does not need to be converted into search queries. These structured listing posting parameters include the display location and format of key information after listing. Furthermore, even for the same target branch link, the corresponding key information slot templates differ depending on the target service type, primarily due to variations in slot type.

[0027] Furthermore, within the same target branch link, due to the different service priorities corresponding to different target service types, the inference-based slot templates and non-inference-based slot templates for different target service types also differ. Based on this, within the target branch link corresponding to the same initial intent, the corresponding importance level can be dynamically determined for each slot of different target service types. The importance level is used to characterize the business importance of each key piece of information relative to the current service type. When generating key information slot templates adapted to the target service type, each slot is first dynamically sorted according to its importance level, and then inference-based slot templates and non-inference-based slot templates are generated sequentially according to the sorting results, making the slot field order different for different target service types under the same initial intent. The dynamically sorted slot templates are used for subsequent slot filling and target operations to achieve a personalized interactive experience of "same fields but different order". For each slot in different target service types, the importance level is dynamically determined. The importance level is used to characterize the business importance of each key information relative to the current service type. When generating key information slot templates adapted to the target service type, the slots are first dynamically sorted according to their importance level, and then inference-type slot templates and non-inference-type slot templates are generated sequentially according to the sorting results. The specific implementation method can be found in the relevant description of the following embodiments, and will not be repeated here. Through the dynamic sorting mechanism of "service type-specific weight vector + session-level online learning", different service types under the same initial intent can generate personalized dual templates with the same fields but different order, strategies, and interaction levels, realizing zero-code hot expansion of "same fields, different experiences", significantly improving filling efficiency and user satisfaction.

[0028] Regardless of the type of key information slot template, the key information slot template is a standardized list of fields dynamically generated by the second model based on the target service type. It is used to extract structured parameters from the user's input requirements. The key information slot template includes at least field names, data types, and required fields. It tells the subsequent filling engine which 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 queryable or publishable database field corresponding to the target service type. It is used to clarify the specific business dimension corresponding to the subsequent slot filling, such as "subway station name", "budget price", "apartment type", "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 under the current target service type. This triggers 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 "renting 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 required information to executable retrieval.

[0029] In addition, the second major model may be the same or different depending on the service type. However, regardless of whether the second major model is the same for different service types, the second major model can be an AI major model. For a detailed explanation and examples of the AI ​​major model, please refer to the relevant description of the first major model mentioned above, which will not be repeated here.

[0030] Furthermore, the initial key information (i.e., keywords) contained in user demand information may correspond to different inference depths. For key information (i.e., keywords) with different inference depths, slot templates of different inference depth types can be developed. Inference depth refers to the semantic processing level required when the key information input by the user is transformed into its corresponding key semantic information. Key semantic information refers to the actual meaning expressed by the corresponding key information. In other words, inference depth is used to quantify "the minimum number of intermediate semantic transformations required to transform each key information contained in the user demand information into its corresponding key semantic information." If there is at least one jump in the transformation path from "key information → literal meaning → intermediate semantics (semantic vector) → key semantic information," then the inference depth = 1, corresponding to "inference type." If the corresponding key semantic information can be obtained directly from literal or synonym normalization in one step, then the inference depth = 0, corresponding to "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 used for property retrieval or property posting in the property database when performing semantic analysis on user demand information. Therefore, inference depth types can include: inference type and non-inference type. Correspondingly, slot templates can include: inference-based key information slot templates and non-inference-based key information slot templates. Inference-based key information slot templates are generated based on inference-based key information, while non-inference-based slot templates are generated based on non-inference-based key information. Inference-based information refers to information that cannot be directly matched literally and requires semantic understanding, logical deduction, or spatial conversion to be transformed into executable parameters. For example, "30-minute commute" requires combining transportation methods and road conditions to deduce the spatial range; "well-lit house" requires inferring implicit attributes such as floor level and orientation; and "school district house" requires associating educational resources and administrative zoning information. This type of information needs to be filled into slots by a large model using chain-like thinking. Non-inference-based information refers to tagged information that can be directly and accurately matched with database fields. For example, keywords such as "three-bedroom apartment," "8000 yuan / month," "entire apartment rental," and "floor" can be directly mapped to database columns through dictionaries or rules. This type of information can be filled into slots by a lightweight model according to preset rules to achieve rapid response. The inference-type slot template contains fields that require semantic reasoning from a large model to be filled (such as "commuting time" and "budget range"). The inference-type slot template can include corresponding chain thinking and function call rules for subsequent slot filling.Chain-like thinking refers to the autoregressive process by which the large model generates the mapping relationship between intermediate semantics 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 inference iteration without adding extra requests. It is used to break down complex requirements into multiple sub-steps, ensuring that the final parameters are computable and interpretable. Function call refers to the interface action of the large model actively triggering a preset function at the end of the chain-like thinking 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 thinking and outputs the function call instruction; after parsing the instruction, the system immediately executes the inference function, and the returned result is directly written into the corresponding slot field. Therefore, the function call is not a Remote Procedure Call (RPC). Instead, the large model generates a call statement that conforms to preset rules, which is then executed locally by the framework. This instantaneously transforms the semantic inference results into executable parameter values, completing the final assignment of inference-type slots. Additionally, the non-inference-type slot template contains fields that can be directly filled using literal matching or lightweight rules (such as "apartment type" or "floor"). These non-inference-type slot templates can include preset field value ranges or regular expression matching rules to guide the lightweight model in slot filling. This classification method distributes mixed inputs according to processing difficulty to the most suitable processing unit (large models handle inference-type inputs, small models handle non-inference-type inputs), achieving a synergistic improvement in high accuracy and low latency within the same process flow.

[0031] Furthermore, after obtaining the key information slot template, referring to step 106, the target operation corresponding to the refined intent can be executed based on the key information slot template to obtain the operation result. The target operation corresponding to the refined intent is the operation pointed to by the target service type corresponding to the refined intent. Specifically, the slots can be filled based on the key information slot template to obtain structured parameters, and then the target operation pointed to by the target service type can be executed based on the structured parameters. Among them, obtaining structured parameters means encapsulating the key-value mapping set formed after slot filling, where the field names and field values ​​are standardized and conform to the housing database specifications, into a JSON object (or other equivalent structured format) that can be directly consumed by the downstream search engine. Each record in this object contains: field name, and the field name corresponds one-to-one with the housing database query field (such as district, price_max, room_type); field value, and the field value is the final valid value after normalization, deduplication, and unit unification (such as "Chaoyang District", "8000", "3 rooms"); type tag, that is, additional inference / non-inference tag, used for subsequent main query and filtering. Therefore, obtaining structured parameters can be understood as completing the final standardization step from natural language to executable query statements, ensuring that no further cleaning or mapping is needed in subsequent retrieval stages. From a higher-level perspective, the target operation refers to the property search operation and the property posting operation; from a more detailed perspective, it refers to the operation pointed to by the target service type within the scope of the property search operation and the property posting operation. Furthermore, as shown in the above embodiments, the key information slot template includes inference-type key information slot templates and non-inference-type key information slot templates. More specifically, the inference-type key information slot template can be filled with slots based on inference-type key information to obtain inference-type structured parameters, and the non-inference-type key information slot template can be filled with slots based on non-inference-type key information to obtain non-inference-type structured parameters. Then, the target operation corresponding to the refined intent is executed by combining the inference-type and non-inference-type structured parameters. For example, if the target service type is "posting properties by community," then the corresponding target operation is "posting properties by community by combining inference-type and non-inference-type structured parameters."

[0032] The above embodiments provide an overall overview of the solution of this application. For the specific implementation of steps 101-106, please refer to the relevant descriptions of the following embodiments, which will not be repeated here.

[0033] The technical solutions provided in the above embodiments of this application elevate the property listing and rental process from traditional form filling to a branch link mapping level of intent recognition through a unified service interface, and this intent recognition is a phased and progressive process. Specifically, firstly, the first large model completes initial intent recognition based on demand information, thereby mapping natural language into the target branch link corresponding to property rental or property listing. Then, based on an attention mechanism, refined intent recognition is performed to determine the target service type on the target branch link, completing a progressive intent recognition from coarse to fine granular and a progressive decision from macro intent to micro service type. This unified architecture eliminates the problems of architectural redundancy, component duplication, and high maintenance costs caused by traditional platforms maintaining separate property listing and rental entry points, significantly reducing structural complexity. In addition, the phased intent recognition mechanism, which is executed progressively within the same large model, avoids the accuracy decay caused by multi-model cascading, improves the accuracy of intent recognition, and thus improves the accuracy of determining the target service type. Finally, the second major model on the target branch link that is compatible with the target service type is taken as the target major model, and the target major model is called to generate a slot template that is compatible with the target service type and execute the corresponding target operation (property listing or property search). This not only supports the flexible expansion of service types, but also enables one-click property listing or one-click property search, bringing a good user experience.

[0034] Continuing from the above Figure 1 The implementation of initial intent recognition can be carried out using the first major model to identify the initial intent of the user and the corresponding target branch link. This can be achieved through various implementation methods. Figure 2 A flowchart illustrating an optional implementation of an initial intent recognition method provided in an exemplary embodiment of this application. (See attached diagram.) Figure 2 As shown, this optional implementation includes: 201. The demand information is processed through multiple encodings to obtain the target vector sequence; 202. Embed intent cue vectors at preset positions in the target vector sequence to generate context vectors with prior intent information; 203. Input the context vector into the first model, perform normalized exponential classification on the context vector, and obtain the probability of rental intention and the probability of listing intention. 204. When the maximum probability value between the property rental intention probability and the property posting intention probability is greater than the preset probability threshold, the intention tag corresponding to the maximum probability is taken as the initial intention, and the preset intention link mapping table is queried based on the initial intention to obtain the target branch link and its service type list corresponding to the initial intention. 205. When the maximum probability is less than or equal to the preset probability threshold, generate a prompt message to prompt the user to improve the required information.

[0035] Referring to step 201, the requirement information is subjected to multiple encoding processing to obtain a target vector sequence. An optional implementation manner includes: performing word segmentation, pinyin sequence, and character-level triple encoding on the requirement text corresponding to the requirement information (which may include spoken language, dialect, and typos), and splicing them into a unified vector sequence, which can be called the target vector sequence. Specifically, a lightweight word segmentation tool (such as jieba) can be used to segment the requirement text into word-level units, and each word-level unit is mapped to a word vector with a fixed dimension through pre-trained word embeddings (such as Word2Vec) to form a word vector sequence; the text is converted into pinyin character by character, and the dialect features such as flat and retroflex sounds, front and back nasal sounds, etc. are normalized through a fuzzy sound matrix, and each pinyin character generates a pinyin vector sequence through a character embedding layer. This pinyin vector sequence has the ability to tolerate speech input and typos (such as "Tiancheng" → "Tianchen"); Unicode character embedding encoding is performed on each Chinese character (including punctuation) to generate a character vector sequence. This character vector sequence retains the glyph information and local context and provides a fallback representation for out-of-vocabulary words (such as new community names); further, the following splicing is performed in the feature dimension: for the i-th position in the sequence (corresponding to a word or a character), the word vector, pinyin vector, and character vector are spliced head to tail in the manner of [word vector; pinyin vector; character vector] to form a unified vector at this position (the dimension is the sum of the three). The entire sequence maintains the original length, and each position is a fusion representation of triple encoding, and then it is input into the attention encoding layer for interactive modeling. This splicing method enables the model to obtain word-level semantics, pronunciation similarity, and glyph local features at the same time. For near-sound misspellings such as "Tiancheng (tiān chéng)" and "Tianchen (tiān chén)", even if the word segmentation is incorrect, the pinyin sequence can still retain the similarity, and the character-level encoding retains the glyph differences, thereby improving the error correction recall rate and laying a foundation for improving the accuracy of subsequent intention recognition and the accuracy of determining the target service type.

[0036] In step 202, an intent cue vector is embedded at a preset position in the target vector sequence to generate a context vector with prior intent information. One optional implementation includes injecting a learnable intent cue vector at the beginning of the target vector sequence. The intent cue vector can be a learnable parameter vector with prior intent information, such as placeholders for "[Rental Housing]" or "[Listing Housing]", thus obtaining an intent cue vector with prior intent information. This intent cue vector can be randomly initialized during the model pre-training stage and jointly optimized with the intent classification task during fine-tuning. Its semantic space coordinates encode the prior distribution information of the two intent categories, "Rental Housing" and "Listing Housing". When demand information is encoded and concatenated with this intent cue vector, it is equivalent to explicitly injecting a guiding signal for intent classification into the deep network, enabling the model to prioritize context features related to intent discrimination in the self-attention calculation of the subsequent attention layer, thereby improving the convergence speed and classification accuracy of intent recognition. In addition, the intent cue vector supports hot-swapping updates. When adding a new intent, only the vector dimension needs to be expanded and incrementally fine-tuned, without retraining the entire model backbone, achieving zero-sample intent expansion. An intent cue vector is a context vector that forms an intent prior.

[0037] In step 203 above, the context vector is input into the first large model, and normalized exponential classification is performed on the context vector to obtain the probability of rental intent and the probability of listing intent. Based on the initial intent, a preset intent link mapping table is queried to obtain the target branch link and its service type list corresponding to the initial intent. An optional implementation includes: the last network layer of the model structure of the first large model can be a dual-exit Softmax (i.e., normalized exponential classification or Softmax normalized classification), which can perform normalized exponential classification on the context vector. The two exits output the rental intent probability (P(rental)) and the listing intent probability (P(listing)) in parallel. When the maximum probability of rental intent and listing intent is greater than the confidence threshold τ, the intent corresponding to the maximum probability is determined to be the initial intent. After the model outputs the initial intent, a preset "intent-link" hash table is directly queried to obtain the target branch link and its service type list corresponding to the initial intent, as well as the subsequent second large model entry address, thus completing the target branch link binding. In this embodiment, intent classification and link binding can be completed in a single inference by a single model; the cue vector combined with the dual-exit structure allows new intents to be added by only expanding the exit and mapping table, without retraining the entire large model, achieving zero-sample hot expansion; the attention mask pre-shields irrelevant branch calculations, greatly reducing CPU usage and achieving a lightweight jump effect where intent is the switch. In step 205 above, when the maximum probability is less than or equal to a preset probability threshold, a prompt message is generated to prompt the user to improve their request information. One optional implementation includes: when the maximum probability output by the first model is lower than a preset confidence threshold, it is determined that the current request information is insufficient to clearly distinguish between the intent to "rent a property" or "post a property," thus triggering a "rejection" state; subsequently, the property platform returns a follow-up prompt message to the user through a unified target service interface, such as "Please confirm whether you are renting a property or posting a property?", guiding the user to supplement their request information again until the probability output by the model reaches or exceeds the confidence threshold, thereby completing the accurate identification of the intent. This embodiment can avoid subsequent link errors caused by misjudgment of intent.

[0038] The above and Figure 2 The technical solutions provided in the relevant embodiments enable the first main model to simultaneously obtain word-level semantics, pronunciation error tolerance, and local glyph features through multi-encoding concatenation. This provides stronger robustness against near-sounding misspellings or out-of-vocabulary words, laying the foundation for accurate intent recognition. The embedded intent cue vector in the first part explicitly injects prior information, allowing attention calculation to prioritize intent-related features, significantly improving convergence speed and classification accuracy. The use of dual-exit normalized index classification enables a single model to complete intent classification and link binding in a single inference, greatly reducing latency and CPU usage. The intent cue vector supports hot-swapping updates; when adding a new intent, only the vector dimension needs to be expanded and incrementally fine-tuned, without retraining the backbone, achieving zero-sample intent expansion. When the maximum probability output by the first major model is lower than the confidence threshold, a rejection-based follow-up question is triggered. The follow-up question prompt is returned through the unified target service interface to guide the user to supplement information, avoiding misjudgment of intent that could lead to errors in subsequent links, and ensuring the accuracy of intent recognition and the fault tolerance of the system. Overall, it realizes a paradigm shift from "static forms" to "dynamic intent recognition", builds an end-to-edge collaborative adaptive housing information processing system, and provides higher quality and better experience information services in complex and ever-changing user demand scenarios.

[0039] Continuing from the above Figure 1 Relevant embodiments of refined intent recognition, based on attention mechanisms, combine demand information and target branch links to perform refined intent recognition, and can be implemented in various ways to obtain the user's refined intent. Figure 3 This is a flowchart illustrating an optional implementation of a refined intent recognition method provided for an exemplary embodiment of this application. (See attached flowchart.) Figure 3 As shown, this optional implementation includes: 301. Concatenate the target vector sequence with the sub-service embedding vector sequence of the target branch link to form a joint vector sequence, and add an intent marker at the target position of the joint vector sequence; 302. Perform a one-way attention masking operation on the joint vector sequence to obtain the attention weight matrix. The rows of the attention weight matrix represent the sequence positions in the joint vector sequence, and the weight values ​​in the attention weight matrix represent the importance of the corresponding position sequence to the subsequent predicted service type. 303. Using the target vector sequence as the query vector and the sub-service vectors of each branch link as the key vectors, calculate the attention weight vector. The attention weight vector represents the importance of the requirement information to each sub-service. 304. The intent pointed to by the sub-service corresponding to the maximum value in the attention weight vector is taken as the user's refined intent.

[0040] Step 301 above involves concatenating the target vector sequence with the sub-service embedding vector sequence of the target branch link to form a joint vector sequence, and adding an intent marker at the target position of the joint vector sequence. One optional implementation includes: querying a pre-defined service type list of the target branch link, mapping each service type to a service vector through an embedding layer to obtain a sub-service embedding vector sequence, where each sub-service corresponds to its respective service type; concatenating the target vector sequence with the sub-service embedding vector sequence at the beginning and end along the sequence length dimension to obtain a joint vector sequence; and inserting a learnable intent marker vector at the beginning position of the joint vector sequence, wherein the intent marker vector encodes prior knowledge of the refined intent recognition task during the pre-training stage. Among them, the joint vector sequence allows the large model to perceive the user's complete needs and all candidate service types simultaneously in the same forward propagation, avoiding the cascading of multiple models; it can also provide complete input for the subsequent unidirectional attention mask, so that the needs part can focus on itself and the service type, while the service type only focuses on the needs part, ensuring that there is no information leakage in semantic matching; in addition, the intent tag vector at the starting position explicitly carries the task prior of "refined intent recognition", guiding the cross attention head to focus on key interaction areas and improving the accuracy of sub-service type selection.

[0041] In step 302 above, the one-way attention mask refers to the requirement that, during attention calculation, the query position can only see itself and all positions before it, and cannot see the mask matrix of subsequent positions. In this application, this is specifically manifested as the requirement part (front end) being globally autocorrelated; the service type part (back end) can only see the requirement part and the service vectors already appearing within this part, and cannot "peek" at subsequent service types in advance, ensuring that the weight calculation of each sub-service depends only on user input and traversed information. Its function is to prevent information leakage, such as preventing the "rent a room by subway" sub-service from knowing the embedding of the "rent a room by price" sub-service in advance when calculating its own weight, ensuring that the weight only reflects the true association between user input and the current sub-service; and making each row of the attention weight matrix truly reflect the importance of the context "up to this position" for predicting subsequent sub-services, conforming to the causal logic of progressive decision-making.

[0042] In step 303 above, the calculation of the attention weight vector actually calculates the attention weight vector of the "demand part" to the "sub-services of each branch link", that is, the correlation importance score of the demand information to each service type. The larger the correlation importance score, the greater the correlation importance, and vice versa.

[0043] The above Figure 3 The technical solutions provided by the relevant embodiments enable the first major model to simultaneously perceive the complete context of the user input and the set of candidate service types in the same forward propagation, avoiding the accuracy decay of traditional multi-model cascading; the intention label vector is explicitly injected into the task prior, guiding attention to focus on key interaction areas and improving the convergence speed of refined intention recognition; the position encoding preserves the sequence structure information, ensuring that the dependencies between service types can still be effectively captured even in long sequences, ultimately greatly improving the accuracy of intention recognition and laying the foundation for providing higher quality and better experience information services in complex and ever-changing user demand scenarios.

[0044] From the above Figure 1 As can be seen from the relevant embodiments, the initial intent includes the intent to rent out a property and the intent to publish a property. Moreover, the intent to rent out a property and the intent to publish a property correspond to different target branch links. The following describes the two target branch links corresponding to the intent to rent out a property and the intent to publish a property.

[0045] In this embodiment, when the initial intent is to publish a property listing, the target large model is invoked to generate a key information slot template that matches the target service type. One optional implementation includes: invoking the target large model to identify the inference depth type of multiple key information contained in the demand information; and generating an inference-based property listing slot template and a non-inference-based property listing slot template that match the demand information based on the target service type and the inference depth type of multiple key information. The inference depth type includes inference type and non-inference type.

[0046] Accordingly, based on the key information slot template, the target operation corresponding to the initial intent is executed to obtain the operation result. One optional implementation includes: inputting at least one third key information belonging to the reasoning type and the reasoning-type property listing slot template into the fourth model, and using chain thinking and function calls to complete the slot filling of the reasoning-type property listing slot template to obtain reasoning-type structured property listing parameters; inputting at least one fourth key information belonging to the non-reasoning type and the non-reasoning-type property listing slot template into the lightweight model, and using preset slot filling rules to complete the slot filling of the non-reasoning-type property listing slot template to obtain non-reasoning-type structured property listing parameters; fusing the reasoning-type structured property listing parameters and the non-reasoning-type structured property listing parameters to obtain target structured property listing parameters, which include the specific information of the property and the display format of the specific information of the property after the property is published; and publishing the property based on the target structured property listing parameters to obtain the property publishing result.

[0047] In this embodiment, all third keywords belonging to the reasoning type may belong to the same reasoning task or different reasoning tasks. If multiple third 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, 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.

[0048] To address this, the third keyword belonging to the reasoning type and the reasoning slot template are input into the fourth main model. Chain-like thinking and function calls are used to fill the slots in the reasoning slot template to obtain the reasoning-based structured property listing parameters. Optional implementation methods include: inputting the third keyword belonging to the reasoning type and the reasoning slot template into the fourth main model, triggering the following chain-like thinking calls: if all third keywords belong to the same reasoning task, then all third keywords are merged into a single thought chain information, and this thought chain information is used to progressively parse the implicit semantics of the third keywords, generating at least one intermediate reasoning result; if at least some third keywords belong to different reasoning tasks, ... The reasoning slot template is then 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 third 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 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 property listing parameters corresponding to that sub-template. The local reasoning structured property listing parameters corresponding to each sub-template are merged to obtain the reasoning structured property listing 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 of derivation, used to narrow the solution space or for subsequent steps to continue to call. Its form includes, but is not limited to: semantic label (transportation mode = subway); numerical quantity (radius = 3200 m); parameter package that the function can accept ({center:, radius:}); logical assertion with constraints on subsequent reasoning ("feasible area 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".

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

[0050] If all third keywords belong to the same reasoning task, the implicit semantics of the third 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 third keyword are multiple semantics, the parsing process of any third keyword is divided into multiple sub-steps with the same number of 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; when the implicit semantics of any third keyword are a single semantic, the implicit semantics of any third keyword are parsed step by step using chain-like thinking to generate one intermediate reasoning result.

[0051] If at least some of the third 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 third keywords with tasks through a preset task classification table to obtain task categories, such as commuting, matching, school district or pet task categories; splitting the reasoning slot template horizontally into non-overlapping sub-templates according to the task categories, with each sub-template retaining only the fields required for the same type of task to form an independent reasoning channel.

[0052] 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 contained third 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.

[0053] 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 category, a complete intermediate inference result can be generated within a single request and the function conversion can be completed synchronously. This mechanism avoids repeated invocation 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.

[0054] In some optional embodiments, based on the target service type and the inference depth type of multiple key information, generating inference-based and non-inference-based property listing slot templates adapted to the demand information includes: selecting a set of fields available for the target branch link from a preset field list based on the target service type; matching each field in the field set with multiple key information; marking fields that are successfully matched and whose corresponding key information is inference-based as inference-based fields as inference-based fields, and generating inference-based property listing slot templates based on the inference-based fields; marking fields that are successfully matched and whose corresponding key information is non-inference-based as non-inference-based fields as non-inference-based fields, and generating non-inference-based property listing slot templates based on the non-inference-based fields. By generating property listing models adapted to the target service type and the inference type of key information, diverse listing templates are provided for subsequent property listings. This embodiment uses a two-dimensional filtering approach of "service type field boundary + inference depth," allowing for zero-code expansion of publishing scenarios simply by updating the preset field list online. Under the same service type, deep slots are generated only for inference fields, avoiding redundant empty slots and simultaneously reducing the size of slot templates and response time. Fields are directly mapped to database columns, and the inference depth directly determines the call path, achieving a one-to-one alignment between business semantics and technical execution, thereby improving the efficiency of property rental and / or property publishing.

[0055] In this embodiment, when the user's initial intention is to post a property listing (the demand information includes information related to the target community, such as the name and location of the target community), the target community of the property is definite. Therefore, it is necessary to first determine the target community of the property before posting the corresponding property listing. However, when users input demand information, there may be inaccurate descriptions of the name or location of the target community, which may prevent effective parsing and recall of the target community, resulting in inaccurate property listings or listing failures. For example, the community name entered by the user may include regional information (such as "the community name is 'Tiantongyuan', but the user enters 'Changping Tiantongyuan'"), which is a mixed information type; or, spelling or pronunciation errors may not be recognized: for example, "the community name is 'Tiancheng Community', but the user enters 'Tianchen Community'", which traditional keyword matching cannot capture the approximate relationship, resulting in a pure community name type; or, there may be a lack of location semantic understanding: sometimes users do not directly enter the community name, but describe it through relative location (such as "opposite McDonald's on xx street"), which is a pure location type.

[0056] Based on this, in some optional embodiments, property listings are published based on the target structured property listing parameters to obtain the property listing results. This includes: identifying the information type of the demand information, which includes: pure community name type, pure geographical location type, and a mixed type of community name and geographical location. Different types correspond to different execution steps, as detailed below: If the information type is a pure community name, then perform step a: based on the community name text, perform dual-channel error correction operation of pinyin and Chinese characters to generate a candidate list of community names, and form a set of target communities after associating it with the housing database.

[0057] If the information type is a pure geographic location type, then proceed to step b: based on the geographic location information, perform a location semantic expansion operation, generate a candidate geographic location list based on the expansion operation results, and form a target community set after associating it with the housing database.

[0058] Specifically, the location semantic expansion operation based on geographic location information refers to the situation where the target cell includes multiple partitions (generally, multiple partitions are adjacent). If the number of target cells determined based on geographic location information does not reach the total number of its actual partitions, the location semantic expansion operation is performed until the number of target cells reaches the total number of its actual partitions. Optionally, the location semantic expansion operation based on geographic location information includes: starting from the relative location description input by the user (such as "opposite McDonald's on Street B" or "500 meters from the subway entrance"), first calling the map API to convert it into standard coordinates (POI coordinates), and then gradually expanding the search radius with these coordinates as the center and according to a preset step size until the number reaches a preset recall threshold. The entire process transforms "relative spatial semantics" into "executable spatial range," realizing dynamic and accurate expansion from colloquial location descriptions to a set of physically reachable cells.

[0059] If the information type is a mixed type, then perform the following steps: Step c: Using a cascaded dictionary matching mechanism, redundant regional prefixes are removed based on the hierarchical order of the regional prefixes, resulting in candidate community name fragments and remaining regional word fragments. Step d: Based on the candidate cell name fragments, generate the corresponding Chinese character sequence and Pinyin sequence in parallel, and use fuzzy sound matrix and vector similarity weighted fusion to generate a corrected cell name candidate list; Step e: For the remaining regional word fragments, perform relative position transformation, standard coordinate transformation, and dynamic expansion processing in sequence to obtain a candidate list of geographical locations; Step f: Perform coordinate consistency fusion between the candidate list of cell names and the candidate list of geographical locations to obtain the target cell set.

[0060] Furthermore, after obtaining the target community set, the target communities that match the demand information are determined from the target community set; based on the target structured housing listing parameters, the housing listing operation is performed on the target communities to obtain the housing listing results.

[0061] In this embodiment, when the initial intent is a housing rental intent, the target large model is invoked to generate a key information slot template that matches the target service type. One optional implementation includes: invoking the second large model on the target branch link that corresponds to the target service type, identifying the inference depth type of multiple key information contained in the demand information; and generating an inference-based housing rental slot template and a non-inference-based housing rental slot template that match the demand information based on the target service type and the inference depth type of multiple key information.

[0062] In some optional embodiments, the second major model corresponding to the target service type on the target branch link is invoked to identify the inference depth type of multiple key information contained in the demand information, including: inputting the demand information into the second major model, splitting the demand information into key information according to the overall intent corresponding to the demand information to obtain multiple key information; performing attribute analysis on each key information, and determining the inference depth type of each key information based on the attribute analysis results.

[0063] Optionally, the demand information is input into the second major model, and the demand information is decomposed into key information based on the overall intent corresponding to the demand information to obtain multiple key information. The optional implementation methods include: inputting the demand information into the second major model, performing deep intent inference, and outputting attitude labels, attitude-targeted entities, and user's real positive demand description information; if the attitude is rejection, the entity targeted by rejection is inverted as the final key information, otherwise the original candidate fragment is directly retained as the final key information; generating a list of key information that has removed negative expressions and expresses the real demand, and associating it with the original offset for use in subsequent attribute analysis steps. The attitude label is a macro-level stance marker determined by the user's entire request information. Its values ​​include accept, reject, or neutral. Accept indicates that the user explicitly "want / hopes / must" a certain characteristic; reject indicates that the user explicitly "does not / excludes / refuses" a certain characteristic; and neutral indicates that 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... The standardized stem, for example, in "Don't look for a house where you can't keep cats," the attitude-pointing entity is "can't keep cats," and in "Preferably with an elevator," the pointing entity is "with an elevator." This entity serves as the target point for reverse correction, used to determine key information fragments that need to be reversed or retained. The user's true positive demand description is the core user demand re-expressed in affirmative sentences 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 true positive demand description guides the inversion generation in the key information decomposition stage, ensuring that the final key information directly reflects the user's true demand. The original offset refers to the character-level position information of the key information in the user's original input text, that is, the starting and ending character indices of the key information in the entire 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 key information "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 key information 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 housing search.

[0064] Optionally, attribute analysis is performed on each key piece of information, and the reasoning depth type of each key piece of information is determined based on the attribute analysis results. This includes: first, performing dependency analysis on each key piece of information to obtain syntactic attributes; second, querying a pre-defined 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 key pieces of information 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 key information has spatial, temporal, or temporal characteristics that require further reasoning. This set of syntactic features includes, but is not limited to: dependency arc type (such as obl, amod, nmod, etc.), part-of-speech tagging of the first word, 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 a 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 key information 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 the property listings in the past N days. The product of Rate (CTR) weights supports O(1) reads and is used to quantify the business scarcity of key information. 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 to achieve a conservative strategy. Then, the syntactic attribute, semantic attribute and business scarcity attribute are input into the deterministic decision-maker. According to the preset if-else rule, the inference depth type label of the key information is output in real time to obtain at least one first key information belonging to the inference type and at least one second key information belonging to the non-inference type, which are used for subsequent large model slot filling and small model slot filling, respectively. Among them, the if-else rule refers to the hard-coded condition sequence solidified in the deterministic rule engine. It accepts three types of attributes, namely syntactic, semantic and business scarcity, as inputs and outputs "inference type" or "non-inference type" label. There are no machine learning parameters and hot updates are supported.This embodiment achieves parallel parsing of syntax, semantics, and business scarcity at the key information level through three-level attribute fusion and a deterministic decision-maker. This ensures that the subsequent differentiated slot filling obtains key information sources with no attribute conflicts and accurate inference depth labeling. Thus, it 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 housing search.

[0065] In some optional embodiments, based on the target service type and the inference depth type of multiple key information, generating inference-based and non-inference-based rental space templates adapted to demand information includes: obtaining at least one inference-based key information and non-inference-based key information based on the target service network type and the inference depth type of each key information; determining the importance of at least one inference-based key information; sorting the at least one inference-based key information according to its importance to obtain a first sorting result; generating an inference-based rental space template based on the first sorting result; and determining the importance of at least one non-inference-based key information; sorting the at least one non-inference-based key information according to its importance to obtain a second sorting result; and generating a non-inference-based rental space template based on the second sorting result.

[0066] Optionally, determining the importance of at least one key piece of information may be achieved by: calculating a basic statistical score, a scenario hit score, and a personalized preference score for at least one inference-based key piece of information; calculating a first business relevance score corresponding to at least one inference-based key piece of information based on the basic statistical score, scenario hit score, and personalized preference score for at least one inference-based key piece of information; and determining the importance of at least one non-inference-based key piece of information based on the first business relevance score corresponding to at least one inference-based key piece of information.

[0067] The basic statistical score reflects the scarcity and business value of inferential key information in the historical data of the entire housing platform. The basic statistical score is determined by the inverse document frequency (IDF) of the inferential key information in the housing query log and the housing click weight. For example, the basic statistical score is determined by multiplying the inverse document frequency of the inferential key information by its housing click weight. A higher score indicates that the inferential key information is rarer and more important to users. The inverse document frequency reflects the scarcity of inferential key information in the entire query space and can be calculated as follows: IDF = In(Total queries ÷ Query count containing this term + 1). A larger result indicates a lower frequency of occurrence of the inferential key information and higher distinguishability. The housing click weight reflects the relative attractiveness of the housing associated with the inferential key information in historical exposure and can be calculated as follows: Housing click weight = Number of clicks on the housing with the inferential key information ÷ Number of exposures of the housing containing the inferential key information. A higher value indicates that the housing corresponding to the inferential key information is more favored by users and has greater business value. The scenario hit score measures the immediate matching degree between inferential key information and current demand information. It is determined by the explicit matching degree of the inferential key information in the current user session and the weight of the matching position. A perfect score is awarded if the inferential key information appears in its entirety, the second highest score is awarded if a synonym appears, and a score of zero is awarded if it does not appear. The personalized preference score reflects the deviation of the inferential key information from the user's historical preferences. The personalized preference score is determined by the user's interest in the property corresponding to the inferential key information, or in other words, by the explicit matching degree of the inferential key information in the current user session and the weight of the matching position. The explicit match score measures the degree of overlap between the user's query text and the property listing field. It is scored only when the inferential key information appears completely and continuously in the property title, description, or tags. For example, a perfect match is scored as follows: the key information matches the field content word for word, with a score of 1; a prefix / suffix match is scored as follows: the key information is at the beginning or end of the field, with a score of 0.8; a substring match is scored as follows: the inferential key information is contained but not at the beginning or end, with a score of 0.6; and no match is scored as follows: 0. This score is used to quickly amplify intuitive relevance during the initial screening stage. Matching position weight refers to further measuring the importance of the location where key information appears, based on explicit matching. For example, to reflect business priors, the title area has a weight of 1; core tags (such as "subway entrance" or "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 whose titles and core tags match during the sorting stage, thereby increasing the click-through rate of the first few results.

[0068] Optionally, based on the basic statistical score, scenario hit score, and personalized preference score of at least one inference-type key information, a first business relevance score corresponding to at least one inference-type key information 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-type key information, which is used as the first business relevance score corresponding to at least one inference-type key information.

[0069] Furthermore, at least one key piece of information is sorted according to its importance to obtain a first sorting result. This sorting is not a simple sequential order, thus making the slots in the subsequent non-reasoning-based rental slot template more aligned with actual business priorities. Optionally, based on the first sorting result, a reasoning-based rental slot template is generated. Further implementation methods include: generating reasoning slots and their arrangement order based on the first sorting result, and generating a reasoning-based rental slot template based on the reasoning slots and their arrangement order.

[0070] Similarly, the optional implementation methods for determining the importance of at least one second key piece of information can be found in the above description of determining the importance of at least one first key piece of information, and will not be repeated here.

[0071] Accordingly, based on the key information slot template, the target operation corresponding to the initial intent is executed to obtain the operation result. One optional implementation includes: inputting at least one first key information belonging to the reasoning type and the reasoning-type rental slot template into the third model, and using chain thinking and function calls to fill the slots of the reasoning-type rental slot template to obtain reasoning-type structured rental parameters; inputting at least one second key information belonging to the non-reasoning type and the non-reasoning rental slot template into the lightweight model, and using preset slot filling rules to fill the slots of the non-reasoning rental slot template to obtain non-reasoning-type structured rental parameters; fusing the reasoning-type structured rental parameters and the non-reasoning-type structured rental parameters to obtain target structured rental parameters; mapping the target structured rental parameters to a rental search statement, using the reasoning-type fields in the rental search statement as the main query conditions and the non-reasoning-type fields as the filtering query conditions to perform a rental search, and obtaining rental search results, which include the target rental set.

[0072] Optionally, at least one first key piece of information belonging to the reasoning type and the reasoning-type rental slot template are input into the third major model. The slots of the reasoning-type rental slot template are filled using chain-like thinking and function calls to obtain the reasoning-type structured rental parameters. This includes: inputting the first key piece of information belonging to the reasoning type and the reasoning-type slot template into the second major language model, and triggering the following chain-like thinking calls: merging the first key piece of information into a thought chain, and using the thought chain to gradually parse the implicit semantics of the first key piece of information to generate at least one intermediate reasoning result; calling a preset function to convert the at least one intermediate reasoning result corresponding to the thought chain into executable parameter values, and writing the executable parameter values ​​into the corresponding fields of the slot template to obtain the reasoning-type structured parameters corresponding to the slot template. The "thinking chain information" refers to a progressively unfoldable intermediate semantic-numerical workflow that encapsulates all the primary key information belonging to the same reasoning task and its context. This workflow guides the third major model in step-by-step derivation, function invocation, and ultimately, the generation of executable parameter values. Its content includes at least: task type labels (e.g., "commuting"), initial known quantities (e.g., "20 min", "Wangjing West Subway"), a pre-defined list of reasoning steps (transportation mode → speed → radius → function call), and intermediate semantic labels / numerical templates for the expected output of each step. Intermediate inference results refer to intermediate semantic and numerical units generated at any single-step derivation stage of a chain of thought processes. These units are used to narrow down the solution space or are invoked by subsequent steps. Their forms include, but are 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 constrain subsequent inference ("feasible areas must exclude highway sections"). In short, intermediate inference results are not the final slot values, but are necessary to obtain the final slot values, thus constituting "at least one intermediate inference result."

[0073] Optionally, merging multiple first key pieces of information into a single thought chain information includes: encapsulating multiple first key pieces of information belonging to the same reasoning task and their parsed values ​​into initial quantities; loading the step-by-step derivation template corresponding to the task from a pre-set reasoning step library to form a structured thought chain information object containing "initial quantity - step sequence - expected output of each step"; and using it as context to enable the large model to output intermediate semantic labels and values ​​step by step; and immediately calling a pre-set function to convert the result of each step into executable parameters and backfilling them into the corresponding slots, thereby completing multi-step reasoning and functional transformation within a single model call.

[0074] Optionally, the implicit semantics of the first key information are parsed step by step using the thinking chain information to generate at least one intermediate reasoning result. Optional implementation methods include: when the implicit semantics of any first key information consists of multiple semantics, the parsing process of that first key information is divided into multiple sub-steps equal to the number of its implicit semantics based on the parsing steps contained in the thinking 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 key information is a single semantic, the implicit semantics of that first key information are parsed step by step using chain-like thinking to generate one intermediate reasoning result.

[0075] Optionally, at least one second key information belonging to the non-reasoning type and the non-reasoning rental slot template are input into the lightweight model, and the slots of the non-reasoning rental slot template are filled based on the preset slot filling rules to obtain non-reasoning structured rental parameters. Optional implementation methods include: filling the slots of the non-reasoning slot template based on the preset slot filling rules to obtain non-reasoning structured parameters. Among them, 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. 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., if both "entire apartment" and "shared apartment" appear, the earlier one takes precedence); mandatory and default fields (e.g., if not specified). The process involves retrieving "rent" and filling it with the default rent range for the city. All preset slot filling rules exist in if-else or lookup table form, supporting hot updates. This ensures that the small model channel completes non-reasoning slot assignment within milliseconds, and the output fields comprehensively conform to the preset rules of the housing database. Thus, the lightweight model handles literal matching and explicit information with fast response, while the large model handles reasoning, processing implicit needs and demonstrating strong semantic understanding, thereby achieving optimal resource allocation and performance optimization. In summary, the system can achieve millisecond-level response using lightweight rules and deep semantic reasoning using the large model, ultimately achieving a synergistic improvement in high accuracy and low latency within the same process.

[0076] Optionally, the target structured rental intent parameters are mapped to a rental search statement. The search is performed using inference-type fields in the search statement as the main query condition and non-inference-type fields as filtering query conditions to obtain rental search results. The rental search results include a target rental set. Optional implementation methods include: mapping the slot name, first key information, and second key information in the target structured intent parameters to the query fields one-to-one to obtain a rental retrieval statement executable by the rental platform. The first key information can be mapped to an inference-type field, and the second key information can be mapped to a non-inference-type field. The search is then performed on the rental platform using the inference-type fields in the rental retrieval statement as the main query condition to obtain a candidate rental set. Finally, the search is performed on the candidate rental set using the non-inference-type fields in the rental retrieval statement as filtering query conditions to obtain the target rental set. The two-level search strategy of "main search of inference fields + filtering of non-inference fields" decouples recall relevance from computational overhead. Furthermore, this mapping and hierarchical mechanism ensures that high-value properties are prioritized in the candidate property set, while low-value properties are screened early, thereby improving the hit rate of the first round of results with zero additional computing power and laying the foundation for improving the overall accuracy and efficiency of property search.

[0077] It should be further explained that, typically, when the initial intention is to rent a property, a property search must first be conducted based on the user's needs. This property search involves two search paths: If the user's needs include information about a target neighborhood, such as the neighborhood's name, location, or relative location (e.g., "want to rent a house in ** neighborhood (or a specific location, or relative location) that meets ** criteria"), then the search will first focus on the target neighborhood (or location, or relative location), and then search for properties within that target neighborhood that meet the "** criteria." If the user's needs do not include information about a target neighborhood, such as "want to rent a house that meets ** criteria," then the search will directly focus on the "** criteria," without needing to search for a neighborhood.

[0078] If the user's request information includes information about the target community, the target community must be located first. For the specific implementation method of locating the target community, please refer to the relevant description in the above embodiment where the initial intent is to publish housing information, which will not be repeated here.

[0079] The technical solution provided by the aforementioned initial intent for the relevant embodiments of housing rental intent adopts a three-dimensional scoring mechanism of "basic statistics - scene hit - personalization". Within the same feature space, it quantitatively integrates the scarcity, immediate relevance, and user preferences of inference-based and non-inference-based key information, thereby generating a first business relevance score and a second business relevance score. Based on the scores, the importance of key information can be assessed, thereby guiding the order and location arrangement of slot filling, effectively improving slot filling efficiency and laying the foundation for improving the accuracy and efficiency of overall housing search. Furthermore, the first and second business relevance scores free the admission thresholds of inference-based and non-inference-based key information from dependence on human experience and directly drive the diversion decision between the large and small models. This ensures that high-value, high-matching, and high-user-preference terms are preferentially entered 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 housing search.

[0080] The information processing method has now been completed, significantly reducing the complexity of the page architecture and process. It also supports flexible expansion of service types and enables one-click property listing or one-click property search, providing users with a good user experience.

[0081] Figure 4 A schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. For example... Figure 4 As shown, the electronic device includes: a memory 40a and a processor 40b; the memory 40a is used to store a computer program; the processor 40b is coupled to the memory 40a and is used to execute the computer program to perform the steps in the above method.

[0082] Furthermore, such as Figure 4 As shown, the electronic device also includes: a communication component 40c, a display 40d, a power supply component 40e, an audio component 40f, and other components. 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.

[0083] in addition, Figure 4 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 4The 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 4 The component within the dashed box.

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

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

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

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

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

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

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

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

[0092] 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, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0093] 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, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0094] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

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

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

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

[0099] 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. An information processing method, characterized in that, include: The system responds to input operations in the target service interface provided on the service page and obtains the user's input request information. The target service interface is a unified entry point for the user to publish or rent out properties. The first major model is used to identify the initial intent of the demand information to obtain the user's initial intent and the target branch link corresponding to the initial intent. The initial intent includes the intent to rent a property and / or the intent to post a property. The intent to rent a property and the intent to post a property correspond to different branch links. Each branch link includes multiple service types and a second major model adapted to each service type. The service types on different branch links are different. Based on the attention mechanism, the user's refined intent is obtained by combining the demand information and the target branch link. Based on the refined intent, the target service type on the target branch link is determined, and the second major model on the target branch link that is adapted to the target service type is taken as the target major model. Invoke the target large model to generate a key information slot template that matches the target service type; Based on the key information slot template, the target operation corresponding to the refined intent is executed to obtain the operation result.

2. The method according to claim 1, characterized in that, The first major model is used to perform initial intent recognition on the demand information to obtain the user's initial intent and its corresponding target branch link, including: The requirement information is subjected to multiple encoding processes to obtain a target vector sequence; An intent cue vector is embedded at a preset position in the target vector sequence to generate a context vector with prior intent information; The context vector is input into the first large model, and the context vector is normalized and classified by index to obtain the probability of rental intention and the probability of listing intention. When the maximum probability value between the property rental intention probability and the property posting intention probability is greater than a preset probability threshold, the intention tag corresponding to the maximum probability is taken as the initial intention, and a preset intention link mapping table is queried based on the initial intention to obtain a list of target branch links and their service types corresponding to the initial intention. When the maximum probability is less than or equal to a preset probability threshold, a prompt message is generated, which is used to prompt the user to improve the required information.

3. The method according to claim 2, characterized in that, Based on an attention mechanism, and combining the demand information and the target branch link, refined intent recognition is performed to obtain the user's refined intent, including: The target vector sequence is concatenated with the sub-service embedded vector sequence of the target branch link to form a joint vector sequence, and an intent marker is added to the target position of the joint vector sequence; A one-way attention masking operation is performed on the joint vector sequence to obtain an attention weight matrix. The rows of the attention weight matrix represent the sequence positions in the joint vector sequence, and the weight values ​​in the attention weight matrix characterize the importance of the corresponding position sequence to the subsequent prediction service type. Using the target vector sequence as the query vector and the sub-service vectors of each target branch link as key-value vectors, an attention weight vector is calculated. The attention weight vector represents the importance of the requirement information to each sub-service. The intent pointed to by the sub-service corresponding to the maximum value in the attention weight vector is taken as the user's refined intent.

4. The method according to claim 1, characterized in that, The initial intent is the intent to rent out the property. Invoke the target large model to generate a key information slot template that matches the target service type, including: The target large model is invoked to identify the inference depth type of multiple key information contained in the demand information; based on the target service type and the inference depth type of the multiple key information, inference-type housing rental slot templates and non-inference-type housing rental slot templates adapted to the demand information are generated, and the inference depth type includes inference type and non-inference type. Accordingly, based on the key information slot template, the target operation corresponding to the initial intent is executed to obtain the operation result, including: Input at least one key piece of information belonging to the reasoning type and the reasoning-type rental slot template into the third model. Use chain thinking and function call to fill the slots of the reasoning-type rental slot template to obtain the reasoning-type structured rental parameters. Input at least one second key piece of information belonging to the non-reasoning type and the non-reasoning housing rental slot template into the lightweight model, and fill the slots of the non-reasoning housing rental slot template based on the preset slot filling rules to obtain non-reasoning structured housing rental parameters. By integrating the reasoning-based structured property rental parameters and the non-reasoning-based structured property rental parameters, the target structured property rental parameters are obtained. The target structured rental parameters are mapped to a rental search statement. The search is performed using inference fields in the rental search statement as the main query conditions and non-inference fields as the filter query conditions to obtain rental search results, which include the target rental set.

5. The method according to claim 1, characterized in that, The initial intent is the intent to post property listings; Invoke the target large model to generate a key information slot template that matches the target service type, including: The target large model is invoked to identify the inference depth type of multiple key information contained in the demand information; based on the target service type and the inference depth type of the multiple key information, inference-based and non-inference-based property listing slot templates adapted to the demand information are generated, and the inference depth type includes inference type and non-inference type. Accordingly, based on the key information slot template, the target operation corresponding to the initial intent is executed to obtain the operation result, including: Input at least one third key piece of information belonging to the reasoning type and the reasoning-type property listing slot template into the fourth model. Use chain thinking and function call to fill the slots of the reasoning-type property rental slot template and obtain the reasoning-type structured property listing parameters. Input at least one fourth key piece of information belonging to the non-reasoning type and the non-reasoning type property listing slot template into the lightweight model, and fill the slots of the non-reasoning property listing slot template based on the preset slot filling rules to obtain the non-reasoning type structured property listing parameters. By integrating the inference-based structured property listing parameters and the non-inference-based structured property listing parameters, the target structured property listing parameters are obtained. Based on the target structured property listing parameters, property listings are published to obtain the property listing results.

6. The method according to claim 5, characterized in that, Based on the target service type and the inference depth type of the multiple key information, inference-based and non-inference-based property listing slot templates adapted to the demand information are generated, including: Based on the target service type, select the set of fields available for the target branch link from the preset field list; Match each field in the field set with the plurality of key information; Fields that match successfully and whose corresponding key information is inference-type key information are marked as inference-type fields, and inference-type property listing slot templates are generated based on the inference-type fields; Fields that match successfully and whose corresponding key information is non-inference key information are marked as non-inference fields, and non-inference property listing slot templates are generated based on the non-inference fields.

7. The method according to claim 5, characterized in that, Based on the target structured property listing parameters, property listings are published to obtain the following results: The information type of the required information is identified, including: pure community name type, pure geographic location type, and a mixed type of community name and geographic location; If the information type is the pure community name type, then step a is executed: based on the community name text, perform a dual-channel error correction operation of pinyin and Chinese characters to generate a candidate list of community names, and form a target community set after associating it with the housing database; If the information type is the pure geographic location type, then step b is executed: based on the geographic location information, a location semantic expansion operation is performed, and a geographic location candidate list is generated based on the expansion operation result, and a target community set is formed after being associated with the housing database; If the information type is the mixed type, then execute step cf: Step c: Using a cascaded dictionary matching mechanism, redundant regional prefixes are removed based on the hierarchical order of the regional prefixes, resulting in candidate community name fragments and remaining regional word fragments. Step d: Based on the candidate cell name fragments, generate corresponding Chinese character sequences and pinyin sequences in parallel, and use fuzzy sound matrix and vector similarity weighted fusion to generate a corrected cell name candidate list; Step e: For the remaining regional word fragments, perform relative position transformation, standard coordinate transformation, and dynamic expansion processing in sequence to obtain a candidate list of geographical locations; Step f: Perform coordinate consistency fusion between the candidate list of cell names and the candidate list of geographical locations to obtain the target cell set; From the set of target cells, determine the target cells that match the requirement information; Based on the target structured housing listing parameters, a housing listing operation is performed on the target community to obtain the housing listing result.

8. An electronic device, characterized in that, include: Memory and processor; The memory is used to store a computer program; the processor, coupled to the memory, is used to execute the computer program to implement the steps of any one of claims 1-7.

9. 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-7.

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

Images