A target search method, a computing device and a storage medium

Abstract

The application relates to the technical field of electric digital data processing, and specifically discloses a target search method, a computing device and a storage medium, which comprise the following steps: acquiring user queries, context and behavior data, generating Schema grounding type intent recognition prompt words, constructing an implicit demand inference chain and inputting a first language model, generating an intent structure body, a parameter set and an implicit demand label set; determining a target tool, performing field pruning and standardization on the parameter set, acquiring a real-time resource snapshot, calculating a dynamic trend difference and calibrating a spatial redundancy deviation, generating a final tool request and calling; storing candidate trajectories and reviewing and writing into a verified sample library, calculating three types of contract hash values for a new query, performing fusion recall, contract comparison and semantic gatekeeper verification, and if the verification is passed, the intent structure body and the tool request are reused, and right interest right sorting is performed according to the behavior data. The application improves the intent recognition integrity of hotel search, the room source matching success rate and the historical query reuse reliability.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, specifically to a target search method, computing device, and storage medium. Background Technology

[0002] Hotel search is the process by which users query, filter, and book hotels through online platforms, involving matching multiple dimensions of conditions such as location, price, and facilities. As the online travel market expands, users' demands for search accuracy and personalized experiences continue to rise. Traditional search architectures are no longer sufficient to meet the needs of in-depth demand mining and dynamic resource adaptation in complex scenarios. Existing hotel search systems generally rely on keyword matching or end-to-end large-scale model intent recognition, facing four deep-seated challenges in the field of digital data processing: User hotel needs are highly implicit. For example, "traveling with children" implies a need for family rooms and children's facilities, while "weekend vacation" implies a preference for bathtubs and views. Existing large-scale model intent recognition only focuses on extracting explicit parameters and lacks the ability to model the semantic network of the scene and the implicit facility association network, resulting in a systematic deviation between the recommendation results and the user's true expectations. Hotel room availability is highly dynamic, with prices, room type inventory, and vacancy status changing in real time. When assembling the identified intent parameters into tool requests, existing systems do not perform feasibility pre-coupling with the real-time room inventory and map traffic conditions of the central booking system. This often results in no results after the tool is called or results that deviate significantly from the user's budget. At the same time, existing solutions mostly rely on the straight-line distance calculation of spatial grid coordinates, ignoring real-time commuting time, leading to an underestimation of the user's actual travel costs and spatial redundancy bias. Large-scale language models are prone to parameter illusion when outputting structured parameters, filling in default values ​​for enumerated parameters not explicitly mentioned by the user or generating illegal values ​​that exceed the range of enumerated values ​​in the tool interface. Furthermore, the generation of protected business fields by the model poses a data security risk. The historical query reuse mechanism lacks the ability to distinguish business equivalence classes. It mostly relies on the literal similarity of the question text or shallow vector similarity for matching, and fails to distinguish between semantically similar but different business inequalities. Furthermore, high-accuracy intent recognition depends on online reasoning of a large-scale language model, which is costly. Direct caching also lacks effective quality verification and version compatibility mechanisms.

[0003] The aforementioned problems are particularly prominent in intelligent shopping guide scenarios that require frequent calls to external hotel booking interfaces, and there is an urgent need for a target search solution that takes into account implicit demand mining, real-time resource coupling, and highly reliable historical reuse. Summary of the Invention

[0004] The technical problems to be solved by the present invention are: the existing hotel search system does not fully identify users' implicit needs, lacks sufficient coupling between real-time room listings and spatial resources, and has low reliability in reusing historical queries.

[0005] The technical solution of this invention to solve the above-mentioned technical problems is as follows: A target search method, specifically including the following steps: S1. Obtain user natural language queries, session context, and behavioral data including historical hotel browsing and favorite hotels. Read intent definition sets, facility standard lexicons, domain terms, and scenario implicit requirement mapping rules from the business configuration library. Real-time acquisition of input patterns for each intent bound to the hotel search tool. Translate field information into natural language parameter descriptions and inject system prompts to generate schema-based intent recognition prompts. Perform implicit requirement inference on natural language queries based on scenario implicit requirement mapping rules and construct implicit requirement inference chains. Input user queries, session context, behavioral data, implicit requirement inference chains, and dynamic prompts into the first language model to generate intent structures, structured parameter sets, and implicit requirement tag sets.

[0006] S2. Determine the target hotel search tool based on the intent tags in the intent structure. Perform field trimming, type normalization, and protected context field injection on the structured parameter set according to the input pattern to ensure that the parameter format strictly matches the tool contract of the target tool. Associate and index the implicit demand tag set with the tool contract constraints to generate a preliminary tool request. Simultaneously acquire real-time resource snapshots, which include room inventory data from the central reservation system, real-time map traffic data, and spatial grid coordinate data. Calculate the dynamic potential difference between demand and physical resources based on the structured parameter set and the real-time resource snapshots. Identify and calibrate the spatial redundancy deviation caused by the inconsistency between straight-line distance and real-time commuting time. Based on the itinerary planning constraints, perform tension resolution and parameter correction on parameters with inventory conflicts in conjunction with the implicit demand tag set. Generate a final tool request that conforms to the tool contract and invoke it to obtain the hotel room business execution results.

[0007] S3. When a tool call meets the preset success criteria, candidate trajectories are asynchronously collected and stored. These candidate trajectories include a standardized user question, intent structure, parameter structure, implicit requirement marker set, tension resolution record, tool name, parameter body, and session context. A second language model with higher reasoning capabilities than the first language model is used to re-perform intent recognition and parameter extraction on the candidate trajectories under the same dynamic prompts and input pattern constraints. The tool request is then reassembled based on the input pattern constraints. Only when the verification result matches the candidate trajectory in the intent structure, structured parameter set, and implicit requirement marker set... When all five aspects—insertion, tool request, and tension resolution record—are completely consistent, the candidate trajectory is promoted and written into the verified sample library. For newly arriving user queries, the intent contract hash value, parameter contract hash value, and tool request contract hash value are calculated. Based on the verified sample library, a fusion recall of dense vector retrieval and lexical retrieval is performed. The recall results are sequentially subjected to contract consistency comparison and semantic gatekeeping verification. If all pass, the corresponding intent structure and tool request in the verified sample library are directly reused. Before output, the historical browsing or favorite hotels are ranked and weighted according to the behavioral data in the current user session context.

[0008] A computing device, comprising: Processor; memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement a target search method.

[0009] A storage medium storing at least one computer program, which is loaded and executed by a processor to enable a computer to implement a target search method. The beneficial effects of this invention are: 1. By constructing an implicit demand inference chain through the implicit demand mapping rules of the scenario, the deep demands of users, such as facility configuration preferences and itinerary planning constraints, which are not explicitly stated, are made explicit. This enables the first language model to accurately output the intent structure and implicit demand tag set under the schema grounding constraint, which significantly reduces the search bias caused by the lack of implicit demands and improves the completeness and accuracy of hotel intent recognition.

[0010] 2. Based on real-time resource snapshots, calculate dynamic potential difference, calibrate the spatial redundancy deviation between straight-line distance and actual commuting time, and perform tension resolution and parameter correction based on implicit demand mark set before calling the tool. Dynamically adjust the search boundary and budget fluctuation range, effectively remove the limitations of physical resource constraints on search results, and improve the first-time success rate of property matching.

[0011] 3. A second language model is used to conduct offline verification of candidate trajectories at five levels to ensure high-quality access to the verified sample library; new queries are performed through fusion recall and three-level comparison using three types of contract hash values, with semantic gatekeeping verification to ensure the reliability of reuse, skipping the online reasoning stage, and performing rights-based ranking of historically viewed or favorited hotels based on behavioral data, taking into account both reuse efficiency and personalized timeliness. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating the method described in Embodiments 1-4 of the present invention; Figure 2 This is a framework diagram of the system described in Embodiment 5 of the present invention. Detailed Implementation

[0013] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0014] Example 1 like Figure 1 As shown, the present invention provides a target search method, a computing device, and a storage medium, specifically including the following steps: S1. Obtain natural language query, conversation context and behavior data, and generate schema-based intent recognition prompts based on business configuration; construct implicit requirement inference chain, input the first language model to generate intent structure, parameter set and implicit requirement tag set; S2. Determine the target tool based on the intent structure, perform field pruning and normalization on the parameter set, and obtain a real-time resource snapshot; calculate the dynamic potential difference and calibrate the spatial redundancy deviation, and generate the final tool request and call it by combining the implicit demand mark set with tension resolution; S3. After a successful call, the candidate trajectory is stored and offline verified by the second language model and written into the verified sample library; the new query calculates the three types of contract hash values, performs fusion recall, contract comparison and semantic gatekeeping verification, and if it passes, reuses the intent structure and tool request, and performs rights escalation and sorting based on behavioral data.

[0015] Example 2 Preferably, in Embodiment 1, step S1 is specifically implemented through the following steps: S11. Schema grounding-type dynamic prompt word construction, specifically including: S111. In response to a user-triggered search request, the system collects the natural language query statement within the current session via the terminal device. This statement is the hotel search request text entered by the user in a spoken or written form. Simultaneously, the system extracts multi-turn dialogue context from the session management module. This context contains records of at least the most recent three rounds of interaction between the user and the system within the current session period. Each round record saves the user's original question, the system's response, and the corresponding timestamp. Furthermore, the system reads user behavior data from the user profile database. This data includes a list of historically viewed hotel identifiers and a list of saved hotel identifiers generated by the user within the past 30 days. Viewed hotel identifiers are unique codes for hotels with a single visit duration exceeding 5 seconds, while saved hotel identifiers are unique codes for hotels actively saved by the user. These three types of data are asynchronously aggregated to the intent recognition preprocessing module via a message queue. After data cleaning and format standardization, they serve as the input source for subsequent steps.

[0016] S112. The business configuration library adopts a two-tier architecture of relational database and caching layer. The relational database serves as the authoritative data source, while the caching layer uses Redis distributed caching to achieve millisecond-level reads. Internally, the business configuration library stores four core configuration categories: intent definition set corresponding to the current scenario, facility standard vocabulary, domain terminology, and implicit requirement mapping rules for the scenario. The intent definition set contains at least 5 intent records. Each record consists of an intent tag, business description text, and a bound hotel search tool identifier. Intent tag values ​​include nearby search, landmark search, price filtering, facility filtering, and comprehensive ranking. The facility standard terminology contains common hotel industry facility terms and their synonym mappings. For example, a king-size bed room maps to a king-size bed, and a bathtub maps to bathroom facilities including a bathtub. Domain terms include hotel star rating, business district name, transportation hub code, and room type classification code. The scenario implicit requirement mapping rules are a combination of regular expressions and conditional judgment rules, with no fewer than 20 rule entries. Each rule includes a trigger condition, inference dimension, and confidence weight, where the confidence weight ranges from 0.1 to 1.0, with a preferred value of 0.8. The system manages changes to the above configurations through a configuration version number mechanism, with each change triggering a hot update of the cache layer.

[0017] S113. After reading the intent definition set and the implicit requirement mapping rules for the scenario, the system initiates input pattern retrieval requests for the hotel search tools bound to each intent in the current scenario. The input pattern is described in JSON Schema format. The system parses the Schema to extract three types of structured constraint information: field names, enumeration value constraints, and required attributes. Field names include city code, check-in date, check-out date, price minimum, price maximum, bed type preference, business district code, and facility tag list. Enumeration value constraints limit the value range for the bed type preference field to single bed, twin bed, king bed, and multi-bed bed, and limit the value range for the facility tag list to air conditioning, bathtub, gym, swimming pool, free parking, and breakfast. Required attributes are determined by parsing the required field in the Schema, and must include at least the city code, check-in date, and check-out date.

[0018] The system will transcribe the extracted structured constraint information into natural language parameter description paragraphs that are adapted to the semantic understanding logic of the large language model according to the preset transcription template. The transcription template includes three paragraphs: field semantic description, value range description, and mandatory field prompt. Each paragraph is limited to 50 characters.

[0019] S114. The aforementioned natural language parameter description section is injected as a constraint instruction into the pre-constraint area of ​​the system prompt word. This area is located at the beginning of the system prompt word and has a higher weight and priority than subsequent example paragraphs. The system prompt word consists of a four-layer structure: a role definition section, a constraint instruction section, a domain knowledge section, and an output format section. The role definition section clarifies the intent recognition role of the first language model in the hotel search scenario. The constraint instruction section carries the aforementioned natural language parameter description section and adds three types of generation constraints: the first type of constraint prohibits default values ​​for enumeration parameters not explicitly mentioned by the user; the second type of constraint allows enumeration values ​​to be taken only from the schema declaration list; and the third type of constraint performs disambiguation matching on semantically ambiguous fields based on the field description. The domain knowledge section integrates the facility standard vocabulary and domain terminology, embedding them into the prompt word context in key-value pairs. The output format section specifies that the first language model must output the intent structure, structured parameter set, and implicit requirement tag set in JSON format. After sequential assembly of the four layers, a schema-based intent recognition prompt word is generated, and the total length of the prompt word is controlled within 1500 tokens.

[0020] S12. Implicit demand chain inference and online intent recognition, specifically including: S121. The system loads implicit requirement mapping rules for scenarios. These rules are stored in the business configuration library in the form of a combination of regular expressions and conditional judgments. Each rule includes trigger conditions, inference dimensions, and confidence weights. Specific examples of implicit requirement mapping rules for scenarios are as follows: Rule "Family Travel Inference": The trigger condition is that the regular expression matches the query text containing any of the terms "child," "parent-child," or "whole family." The inference dimension is that the facility configuration tends to include family rooms and children's facilities, with a confidence weight of 0.85. Rule "Business Travel Inference": The trigger condition is that the conversation context contains terms such as "business trip" or "meeting," and the check-in date is Monday to Thursday. The inference dimension is that the price range flexibility is reduced by 10%, and priority is given to matching facilities including gyms and business centers, with a confidence weight of 0.90. Rule "Vacation and Relaxation Inference": The trigger condition is that the query text matches terms such as "relax," "vacation," or "weekend," and the check-in date includes Friday or Saturday. The inference dimension is that the facility configuration tends to include bathtubs and view rooms, and the price range flexibility is increased by 20%, with a confidence weight of 0.80.

[0021] The system first performs lexical analysis on the natural language query, segmenting the query text into a sequence of words and tagging them with parts of speech. The segmentation granularity is a hybrid mode of character-level and word-level analysis. Next, it performs syntactic analysis, identifying dependency relationships and core predicates in the query and extracting the association paths between modifiers and core intent. Finally, it performs semantic analysis, combining the most recent three rounds of dialogue from the conversation context and historical preferences from behavioral data to infer the user's unspoken deeper needs.

[0022] If over 80% of a user's hotel browsing history in the past 30 days includes hotels rated four stars or higher, it is inferred that the price range flexibility leans towards the high end. This flexibility ranges from 0% to 50%, with a preferred value of 20%. If the favorited hotel tags are concentrated in a specific business district, it is inferred that the spatial distance tolerance leans towards the surrounding area of ​​that business district. This tolerance ranges from 1 km to 20 km, with a preferred value of 5 km. Facility configuration preference is determined by statistically analyzing the co-occurrence frequency of facility tags in historical hotel browsing history, with a co-occurrence frequency threshold set at 3 times. Itinerary planning constraints are determined by identifying the date span and the number of attractions in the query, with the date span ranging from 1 day to 30 days. The above four dimensions are organized into an implicit demand inference chain using a directed graph structure. Nodes in the graph represent inference dimensions, edges represent dependencies, and edge weights range from 0.1 to 1.0, with a preferred value of 0.8.

[0023] S122. The first language model employs a generative pre-trained model based on a Transformer decoder architecture. It consists of an input embedding layer, a positional encoding layer, 24 Transformer decoding blocks, and a linear output layer. Each decoding block contains a masked self-attention sub-layer, a cross-attention sub-layer, and a feedforward neural network sub-layer. The hidden layer dimension is 4096, the number of attention heads is 32, the intermediate dimension of the feedforward network is 16384, and the activation function is SwiGLU. The model has approximately 7 billion parameters and supports a maximum context length of 32768 tokens.

[0024] Natural language queries are converted into dense vector representations via an input embedding layer. Session context and behavioral data are injected with temporal information via a positional encoding layer. The implicit demand inference chain establishes a deep semantic association with the query vector through a cross-attention sublayer. Schema-based intent recognition prompts are injected as system prompts into a masked self-attention sublayer, constraining the decoding path to adhere to the field specifications of the tool contract. The model performs non-linear feature transformations through a feedforward neural network sublayer, and finally, a linear output layer combines a Softmax probability distribution to generate JSON structured text containing the intent structure, a set of structured parameters, and a set of implicit demand tokens. The output text length is limited to 1024 tokens.

[0025] S123. The system receives the JSON structured text output by the first language model. First, it performs syntax validation using a JSON parser. The validation pass rate threshold is set to 100%, meaning any formatting error triggers a retry mechanism. The maximum number of retries is 3, with a preferred value of 2, and each retry is spaced 1 second apart. After successful validation, the system extracts the intent structure, which includes an intent label field, a confidence level field, and a timestamp field. The intent label value is limited to nearby search, landmark search, price filtering, facility filtering, and comprehensive sorting. The confidence level value ranges from 0 to 1, with a preferred value of no less than 0.85.

[0026] The system synchronously extracts a set of structured parameters, including city code, check-in date, check-out date, price minimum, price maximum, bed type preference, business district code, and facility tag list. The data types of each field strictly match the schema constraints in the input pattern. Missing fields trigger an anomaly flag or are filled in based on the implicit demand inference chain. The system also extracts a set of implicit demand tags from the independent fields output by the model. This set includes spatial distance tolerance values, facility configuration preference Boolean vectors, price range flexibility ratios, and travel planning constraint identifiers. These tags are mapped one-to-one with the implicit demand inference chain constructed in the previous steps through dimension names. Mapping failure triggers an anomaly log, and a preset fallback strategy is used to fill missing dimensions with default values ​​before continuing execution. The default value for spatial distance tolerance is 5 kilometers, the default value for facility configuration preference is an empty vector, the default value for price range flexibility is 0%, and the default value for travel planning constraints is single-day, single-node.

[0027] Example 3 Preferably, in Embodiment 1, step S2 is specifically implemented through the following steps: S21. Tool mapping and real-time resource pre-assembly specifically include: S211. The system maintains a mapping table between intent tags and hotel search tool identifiers. This mapping table is stored in the business configuration database and contains 5 mapping records. Each record consists of an intent tag, a tool identifier, and a tool version number. Upon receiving an intent structure, the system extracts the intent tag field and locates the corresponding hotel search tool identifier in the mapping table using a hash lookup. The hash collision handling strategy uses chaining, and the average query time complexity is constant. After determining the target tool, the system reads the corresponding input pattern for that tool. This input pattern is described in JSON Schema format and includes field names, data types, enumerated values, and required attributes.

[0028] The system performs field pruning on the structured parameter set. The pruning rule is to retain all declared fields in the input pattern and delete all undeclared fields, ensuring 100% field integrity and strict matching of parameter format with the target tool's contract. Subsequently, type normalization is performed, converting string dates to ISO 8601 format, converting price values ​​to integer cents, converting Boolean values ​​to lowercase strings "true" or "false," and sorting array-type facility tags lexicographically to remove duplicates. The protected context field injection operation writes the user session context's membership level, channel source, and device type into reserved fields in the parameter set. Membership level values ​​range from 1 to 5, channel source values ​​range from APP, mini-program, and web, and device type values ​​range from iOS, Android, and Web.

[0029] After completing the above operations, the system generates a standardized parameter set that strictly matches the tool contract, and appends the implicit requirement tag set to the metadata area of ​​the parameter set in the form of key-value pairs, and establishes an associated index. The index key is the requirement dimension name, and the index value is the corresponding tag value. The index structure is implemented using a balanced tree, which supports millisecond-level key-value queries.

[0030] S212. The system initiates a room inventory data query request to the central reservation system via the asynchronous message bus. The request message includes three mandatory fields: city code, check-in date, and check-out date. The message format is Protocol Buffers binary serialization, and the message size is limited to 1024 bytes. The room inventory data returned by the central reservation system includes the hotel's unique identifier, room type code, real-time available rooms, real-time lowest price, and inventory update timestamp. The real-time available rooms range from 0 to 999, the real-time lowest price ranges from 1 to 999999, and the unit is minutes. The inventory update timestamp is accurate to milliseconds.

[0031] The system simultaneously sends a traffic data query request to the real-time map service gateway. The request parameters include the spatial grid coordinates of the target business district or landmark. The returned data includes a road congestion index, average traffic speed, and estimated commute time. The congestion index ranges from 0 to 10, with a preferred value below 5 indicating smooth traffic. The average traffic speed ranges from 0 to 120 kilometers per hour, and the estimated commute time ranges from 1 to 180 minutes. The spatial grid coordinate data uses a GeoHash encoding scheme with a precision level of 6 characters, corresponding to a grid side length of approximately 1.2 kilometers and a coverage area of ​​approximately 1.5 square kilometers. The coordinate origin uses the WGS84 coordinate system. The above three types of data, along with the facility coverage data determined by the completeness score of each hotel facility label, are synchronously aggregated through a time window mechanism. The facility coverage score is calculated based on the matching degree between each hotel facility label in the room inventory data and the preset standard facility list, with a value range of 0 to 1. The time window length ranges from 100 milliseconds to 500 milliseconds, with a preferred value of 200 milliseconds. After aggregation, a real-time resource snapshot is formed, with the snapshot serialization format being JSON and the snapshot size limited to 512 kilobytes.

[0032] S213. The system spatially correlates and matches spatially relevant fields in the standardized parameter set, including city codes, business district codes, and landmark names, with spatial grid coordinate data in real-time resource snapshots. The matching process first converts the business district code or landmark name into WGS84 latitude and longitude coordinates with a conversion precision of 6 decimal places. Then, it uses the Haversine formula to calculate the spherical distance between this coordinate and the center point of the spatial grid coordinates, using an Earth radius of 6371 kilometers and a distance threshold of 2 kilometers, with a preferred value of 1 kilometer. After successful matching, the system binds the price range, bed type preference, and facility tags in the parameter set to the spatial grid coordinates, forming a spatial constraint package.

[0033] The spatial constraint package and the inventory constraint package, including the real-time available room number threshold and the real-time minimum price range, are then logically ANDed to generate a preliminary tool request. The preliminary tool request consists of a request header and a request body. The request header records the tool identifier, version number, and timestamp. The request body records the complete set of parameters after pre-assembly. The request body size is limited to 256 kilobytes, the request timeout is set to 3 seconds (preferred to be 2 seconds), and the number of request retries ranges from 0 to 3 (preferred to be 1).

[0034] S22. Dynamic potential loss resolution and tool contract assembly, specifically including: S221. The system reads the inventory update timestamp from the real-time resource snapshot to determine the freshness of the housing inventory data. When the difference between the timestamp and the current system time exceeds 30 seconds, the system re-acquires the real-time resource snapshot. After successful verification, the system extracts the spatial positioning field from the structured parameter set, including the city code, business district code, and landmark name, and simultaneously reads the spatial grid coordinate data and real-time map traffic data from the real-time resource snapshot. The dynamic potential difference calculation adopts a multi-dimensional vector difference model, mapping the user demand vector and the physical resource vector to the same normalized feature space. The demand vector U=(u1,u2,u3) is defined, where u1 is the normalized value of the median expected price, u2 is the normalized value of the expected distance, and u3 is the normalized value of the expected facility completeness. The resource vector R=(r1,r2,r3) is defined, where r1 is the normalized value of the actual minimum house price, r2 is the normalized value of the actual commuting time, and r3 is the normalized value of the actual facility coverage. Each dimension was normalized to the [0,1] interval using the Min-Max method before calculation. The weights w1, w2, and w3 satisfy w1 + w2 + w3 = 1, with values ​​ranging from 0.1 to 0.8, and an optimal value of 1 / 3. Dynamic potential difference. The calculation formula is: In the formula: This is a dimensionless value, ranging from 0 to 1.0, with a theoretical maximum value of 1.0. The trigger threshold is set to 0.5. Spatial redundancy deviation calibration is initiated when the value is ≥0.5.

[0035] The spatial redundancy deviation calibration module compares the straight-line distance of the spatial grid coordinates with the actual commuting time in the real-time map traffic data. The straight-line distance is calculated using the Haversine formula, while the actual commuting time is estimated from the average traffic speed and road topology in the traffic data. When the congestion index in the real-time map traffic data reaches or exceeds 5, it is determined to be an abnormal traffic state, and spatial redundancy deviation calibration is forcibly initiated. When the congestion index is below 5, the deviation rate is used for determination. The deviation rate is calculated by subtracting the theoretical straight-line distance from the actual commuting time and then dividing by the theoretical straight-line distance. The deviation rate ranges from -50% to +200%. Calibration is initiated when the deviation rate reaches or exceeds 30%. The calibration strategy is to expand the search radius proportionally to the deviation rate, with the expansion coefficient ranging from 1.0 to 3.0, and the preferred value being 1.5.

[0036] S222. The system parses the trip planning constraint field in the implicit requirement tag set. This field includes the trip date span, the number of daily moving nodes, and the maximum tolerable commuting time between nodes. The date span ranges from 1 to 30 days, the number of daily moving nodes ranges from 1 to 5, and the maximum tolerable commuting time between nodes ranges from 15 to 120 minutes, with a preferred value of 60 minutes.

[0037] The system performs field-by-field conflict detection between the search parameters in the initial tool request and the housing inventory data. The detection dimensions include price range overlap, available housing types, facility tag matching degree, and geographical location deviation. The conflict determination threshold is when any dimension fails to meet the minimum admission conditions. If a conflict is detected, the system activates the tension resolution engine. This engine combines the facility configuration preference in the implicit demand tag set with the price range flexibility to perform parameter adjustments. The facility configuration preference is represented by a Boolean vector to indicate the necessity level of each facility item, with a value ranging from 0 to 2, where 0 indicates that it can be discarded, 1 indicates that it should be retained, and 2 indicates that it should be retained. The price range flexibility is represented by a percentage to indicate the budget upward adjustment space, with a value ranging from 0% to 50%, and the preferred value is 20%.

[0038] The tension resolution engine has three built-in resolution strategies and triggering conditions: Strategy 1: When a price range is detected to have no overlap with the inventory price, the upper limit of the price is increased based on the flexibility of the price range in the implicit demand tag set, with the increase ratio not exceeding the flexibility value and a single increase step of 5%; Strategy 2: When a facility tag matching degree is detected to be less than 50%, the facility tag matching degree is calculated by dividing the number of intersections between the requested facility tag and the hotel's actual facility tag by the number of requested facility tags. Facilities with a necessity level of 0 are relaxed first, followed by facilities with a necessity level of 1, and facilities with a necessity level of 2 are not allowed to be relaxed; Strategy 3: When inventory conflicts still exist after S221 spatial redundancy deviation calibration, and the spatial redundancy deviation rate exceeds 30%, the search radius is expanded proportionally to further relax spatial constraints, with an expansion coefficient of 1.0 to 1.5. The three strategies are triggered independently according to the conflict type. Multiple strategies can be executed simultaneously. After each correction, the inventory is queried again for verification. The maximum number of iterations is 5, with a preferred value of 3. The iteration terminates when the conflict is eliminated or the iteration limit is reached. Finally, a tension resolution record is generated, which includes the conflict type, correction item, value before correction, value after correction, and number of iterations.

[0039] S223. The system reads the parameter set after tension resolution and correction. This set includes calibrated spatial grid coordinates, adjusted price ranges, updated facility tag lists, and corrected business district areas. The system performs a final compliance check on the parameter set based on the input pattern of the target hotel search tool. The check items include field integrity, data type correctness, enumeration value validity, and non-emptiness of required fields. The pass rate threshold is set to 100%, meaning that failure of any check item will trigger an abnormal interruption process.

[0040] After successful verification, the system serializes the parameter set into a final tool request conforming to the tool contract. The serialization format is consistent with the input pattern defined by the target tool, and the request body size is limited to 256 kilobytes. The system initiates a call to the target hotel search tool via the HTTP POST protocol. The request header includes an authentication token, version number, and timestamp. The connection timeout is set to 3 seconds, and the read timeout is set to 10 seconds, with preferred values ​​of 2 seconds and 5 seconds, respectively. After receiving the request, the target hotel search tool performs real-time room retrieval and availability verification in the central reservation system. Upon successful verification, it returns the hotel room business execution result, which includes a list of unique hotel identifiers, details of real-time available room types for each hotel, real-time prices, and inventory status codes. The result data volume is limited to 100 records, with a single record size limited to 10 kilobytes. The result is asynchronously returned to the system via a message queue, with a return latency threshold set to 500 milliseconds, with a preferred value of 200 milliseconds.

[0041] Example 4 Preferably, in Embodiment 1, step S3 is implemented through the following steps: S31. Candidate trajectory accumulation and offline high-accuracy verification, specifically including: S311. When the target hotel search tool call meets the preset success criteria, the system triggers the asynchronous candidate trajectory collection process. The success criteria include three layers of verification: the first is HTTP status code verification, requiring a return code of 200; the second is business status code verification, requiring the inventory status code to be available for sale; and the third is data integrity verification, requiring the returned results to contain at least one hotel record, with 100% completeness of required fields and no more than 20% missing optional fields. After successful verification, the system extracts a standardized user question from the call context. This question is standard text after stop word removal and case unification, with a length limit of 512 characters. Simultaneously, the intent structure, parameter structure, implicit requirement marker set, tension resolution records, tool name and parameter body, and session context are extracted. The above data is encapsulated into a candidate trajectory data package according to a fixed schema, with a data package size limit of 1 megabyte. The system stores candidate trajectory data packets into the candidate trajectory database through an asynchronous write thread. The write latency threshold is set to 100 milliseconds, with a preferred value of 50 milliseconds. After a successful write, a unique trajectory identifier is returned. This identifier is a 64-bit unique identifier generated using the snowflake algorithm.

[0042] S312. The second language model adopts a generative pre-trained model based on a hybrid expert architecture, consisting of an input embedding layer, a rotational position encoding layer, a 64-layer hybrid expert decoding block, and a linear output layer. Each decoding block contains a sparse gated routing sublayer, 8 expert attention sublayers, and a feedforward neural network sublayer. The hidden layer dimension is 8192, the number of attention heads is 64, the intermediate dimension of the feedforward network is 32768, the activation function is SwiGLU, the total number of model parameters is approximately 280 billion, and it supports a maximum context length of 131072 tokens. During the offline batch processing period, the system reads the trajectories to be reviewed in batches from the candidate trajectory database. The batch size ranges from 10 to 1000, with a preferred value of 100.

[0043] The system transforms the standardized user questions, conversation context, and implicit demand markers from the candidate trajectories into dense vectors via an input embedding layer. A rotational position encoding layer injects temporal and positional information, and a sparse gating routing sublayer dynamically allocates computational paths to eight expert attention sublayers. Each expert sublayer focuses on four tasks: intent recognition, parameter extraction, implicit demand marker verification, and tool request assembly. The model performs deep feature fusion through a feedforward neural network sublayer, ultimately generating a verified intent structure, structured parameter set, implicit demand marker set, and reassembled tool request via a linear output layer. The output format strictly adheres to JSON Schema constraints. Based on the structured parameter set and implicit demand marker set output by the second language model, and combined with the original housing inventory context data associated with the candidate trajectories, the system re-executes inventory conflict detection and tension resolution deduction, generating deduction tension resolution records for subsequent consistency comparison with the tension resolution records in the original candidate trajectories.

[0044] S313. The system establishes a five-level comparison pipeline, sequentially performing consistency checks on the second language model verification results and the original candidate trajectories: The first level is intent structure comparison, verifying whether the intent label fields are completely consistent, with the absolute value threshold for confidence difference set at 0.05 and the preferred value at 0.02. The second level is structured parameter set comparison, using a depth-first traversal algorithm to compare key-value pairs field by field. When the field value type is string, a complete match is required; when the type is numeric, the relative error for the price field is allowed to be no more than 0.001, the absolute error for the coordinate field is allowed to be no more than 0.0001 degrees, and the absolute error for the confidence field is allowed to be no more than 0.02; when the type is array, the element order is irrelevant but the set is equal. The third level is implicit demand tag set comparison, verifying whether the four dimensions of spatial distance tolerance, facility configuration preference, price range flexibility, and itinerary planning constraints are completely consistent, with a tolerance of 0 for missing dimensions. The fourth level is tool request comparison, which verifies whether the tool name, request path, and request body parameters are completely consistent. The JSON string in the request body is normalized and sorted before calculating its SHA-256 hash value. If the hash values ​​are equal, it is considered consistent. The fifth level is tension resolution record comparison, which verifies whether the conflict type, correction items, and correction magnitude in the tension resolution records are consistent.

[0045] Candidate trajectories are promoted and written to the verified sample library only when all five levels pass the verification. The sample library is stored in a columnar database with a compression ratio ranging from 3:1 to 10:1, with a preferred value of 5:1. After writing, index reconstruction is triggered, with a reconstruction delay threshold set at 5 seconds, with a preferred value of 2 seconds.

[0046] S32. Contract hash calculation and hybrid retrieval recall, specifically including: S321. For newly arriving user queries, the system first quickly generates a draft structure for the current session in lightweight mode. This draft structure is only used to calculate the contract hash value to trigger reuse retrieval and does not directly participate in the final business call. Specifically, the system performs rapid intent recognition and parameter extraction on the user query based on rule matching or a lightweight coding model, generating a draft intent structure, a draft parameter structure, and a draft tool request structure. Then, the system enters the contract hash calculation stage, which employs a three-level hash generation strategy: For the intent structure, the system extracts the intent label and confidence fields, arranges the field names in lexicographical order, concatenates them into a standardized string, and calculates the intent contract hash value using the SHA-256 algorithm. The hash output is a 64-bit hexadecimal character. For the parameter structure, the system performs JSON normalization, including sorting keys and array elements in lexicographical order, converting numeric types to string format, and removing all whitespace characters. The normalized string is then used to calculate the parameter contract hash value using the SHA-256 algorithm. For the tool request structure, the system extracts the tool name, request path, and normalized request body parameters, concatenates them into a standardized string, and calculates the tool request contract hash value. The calculation latency threshold for all three types of hash values ​​is set to 10 milliseconds, with a preferred value of 5 milliseconds, and the hash collision probability is less than 10. -38 After the calculation is completed, the system associates the three types of contract hash values ​​with the current session identifier and stores them in the cache layer. The cache validity period ranges from 300 seconds to 600 seconds, with 300 seconds being the preferred value.

[0047] If the subsequent reuse verification passes, the historical intent structure and historical tool requests in the verified sample library will be reused directly, skipping the complete online reasoning and tool request assembly of the first language model; if the reuse verification fails, the first language model will be started to perform complete online reasoning and tool request assembly.

[0048] S322. The system performs a hybrid search based on a validated sample database, integrating dense vector retrieval and lexical retrieval paths. The dense vector retrieval path employs a dual-tower vector encoding model, encoding the current user query and contract hash value into a 768-dimensional dense vector. The vector magnitude is normalized to 1.0. Approximate nearest neighbor retrieval is performed in the vector index of the validated sample database. The index structure uses an HNSW graph index, with the number of neighbor nodes ranging from 16 to 64, with a preferred value of 32. This parameter controls the graph density during the index construction phase. The retrieval recall is set to 100 results, with a preferred value of 50. This parameter controls the number of results returned during the retrieval phase. These two parameters are configured independently, and the retrieval recall can be greater than the number of neighbor nodes. The lexical retrieval path uses an inverted index structure, employing keywords from the normalized user query as search terms. A combined Boolean and phrase search query is performed in the full-text index of the validated sample database. The retrieval recall is set to 100 results, with a preferred value of 50.

[0049] The fusion and ranking stage employs a weighted reciprocal ranking fusion algorithm. The weight α for the dense vector retrieval path ranges from 0.4 to 0.8, with an optimal value of 0.6. The weight β for the lexical retrieval path ranges from 0.2 to 0.6, with an optimal value of 0.4, and satisfies α + β = 1. For the i-th candidate result, its ranking position in the dense vector retrieval path is denoted as rank. d (i) The ranking position in the lexical retrieval path is denoted as rank. l (i), then the fusion score of the candidate is Score(i) = α × (1 / rank) d (i))+β×(1 / rank l (i)). Generate a set of candidate search results by sorting them in descending order of Score(i). The set size is limited to 50 results, with a preferred value of 20 results.

[0050] S33. Contract comparison and reuse and behavior injection ranking, specifically including: S331. The system initiates a three-level contract consistency comparison pipeline for the candidate search result set. The first level compares the intent contract hash value, performing a bitwise XOR operation between the intent contract hash value of the current query and the intent contract hash values ​​of historical trajectories in the candidate search results, with the Hamming distance threshold set to 0, requiring complete equality. The second level compares the parameter contract hash value, employing the same bitwise comparison strategy, requiring complete consistency of the parameter contract hash values. The third level compares the tool request contract hash value, requiring a complete match between the tool request contract hash value and the request contract hash value.

[0051] After all three levels of comparison pass, the semantic gatekeeping verification stage begins. This stage employs a dual-path verification architecture. The first path is based on embedding similarity, using a dual-tower vector encoding model to encode the current user query into a 768-dimensional dense vector. The cosine similarity is then calculated between this vector and the dense vectors of historical queries in the candidate search results. The similarity threshold ranges from 0.85 to 0.99, with a preferred value of 0.95. The second path is based on a re-ranking model, using a cross-encoder architecture to concatenate the current query and historical queries into an input sequence. A relevance score is calculated using 24 layers of Transformer encoding blocks, with a score threshold ranging from 0.8 to 0.99, and a preferred value of 0.9. If both paths of verification pass, the candidate search result set is deemed semantically consistent.

[0052] S332. When both the three-level contract consistency comparison and semantic gatekeeping verification pass, the system determines that the candidate retrieval result set is eligible for reuse. The system reads the historical intent structure and historical tool request associated with the unique identifier of the candidate retrieval result from the verified sample library. The historical intent structure includes intent tags, confidence levels, and timestamps, while the historical tool request includes the tool name, request path, and serialization parameter body. The system directly reuses the above historical data. Before reuse, it verifies whether the check-in date in the historical tool request is earlier than the current system date. If the check-in date is earlier than the current system date, it is determined to be expired, the historical tool request is discarded, and the online inference step of S1 is re-executed. After the verification passes, the online inference step of the first language model is skipped. This step includes three sub-steps: natural language semantic parsing, intent recognition, and parameter extraction. At the same time, the tool request assembly step is skipped. This step includes three sub-steps: field trimming, type normalization, and protected context field injection.

[0053] After reuse, the system updates the timestamp field in the historical tool request to the current system time, regenerates the sequence number field, and keeps the other parameters unchanged. The updated tool request is resent to the target hotel search tool via the HTTP POST protocol, with the request header containing the refreshed authentication token, a connection timeout of 3 seconds, and a read timeout of 10 seconds. The target hotel search tool performs a real-time room retrieval based on the reused request and returns the hotel room service execution results verified by the central reservation system. The results include a list of unique hotel identifiers, real-time available room types, and price data.

[0054] S333. Before the reuse results are output to the user terminal, the system initiates the rights-based priority ranking process. The system reads the behavioral data in the current user session context and extracts the list of historically browsed hotel identifiers and the list of favorited hotel identifiers generated by the user in the past 30 days. The browsed hotel identifier is a unique code for a hotel where the single stay duration exceeds 5 seconds, and the favorited hotel identifier is a unique code for a hotel recorded when the user actively triggers the favorited operation. The system performs a set intersection operation on the unique hotel identifiers in the reuse results and the above two types of identifier lists to identify the target hotels that belong to the user's historical browsing or favorited history.

[0055] For identified target hotels, the system implements differentiated privilege enhancement. The enhancement score for browsing hotels ranges from 1 to 10 points, with a preferred value of 3 points. The enhancement score for favorited hotels ranges from 5 to 20 points, with a preferred value of 10 points. These enhancement scores are directly added to the hotels' original ranking scores, and the results are then rearranged in descending order of total score for reuse. A priority-based display strategy moves the enhanced hotels forward in the results list, with the move position ranging from 1 to 20 positions, with a preferred value of 5 positions. After sorting, the system serializes the final output into JSON format and pushes it to the user's terminal via a WebSocket channel. The push latency threshold is set to 100 milliseconds, with a preferred value of 50 milliseconds.

[0056] Example 5 like Figure 2 As shown, a target search system is used to implement a target search method, including: The multimodal intent deconstruction module is configured to acquire user natural language queries, conversation context and behavior data, generate schema-based intent recognition prompts based on business configuration, construct implicit requirement inference chains, and call the first language model to generate intent structures, structured parameter sets and implicit requirement tag sets. The space-inventory coupling contract assembly module is connected to the multimodal intent deconstruction module. It is configured to determine the target hotel search tool based on the intent structure, perform field pruning and normalization on the structured parameter set, obtain real-time resource snapshots, calculate dynamic potential difference and calibrate spatial redundancy deviation, and generate the final tool request and call it by combining the implicit demand mark set through tension resolution. The boundary convergence and behavior injection reuse module is connected to the space-inventory coupled contract assembly module. It is configured to store candidate trajectories after the tool is successfully called, call the second language model for offline verification and write it into the verified sample library. For newly arrived users, it queries and calculates three types of contract hash values, performs fusion recall, contract comparison and semantic gatekeeping verification. If it passes, it reuses the intent structure and tool request, and performs rights escalation and ranking based on behavior data.

[0057] The embodiments and / or implementation methods described above are merely preferred embodiments and / or implementation methods for implementing the technology of the present invention, and are not intended to limit the implementation methods of the technology of the present invention in any way. Any person skilled in the art can make some modifications or alterations to other equivalent embodiments without departing from the scope of the technical means disclosed in the content of the present invention, but they should still be regarded as the technology or embodiments that are substantially the same as the present invention.

[0058] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are only preferred embodiments of this application. It should be noted that due to the limitations of written expression, while there are objectively infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this application, and can also combine the above technical features in an appropriate manner. These improvements, modifications, changes, or combinations, or the direct application of the inventive concept and technical solution to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A target search method, characterized in that, include: Acquire natural language query, session context, and behavioral data, and generate schema-based intent recognition prompts based on business configuration; Construct an implicit requirement inference chain, input the first language model to generate an intent structure, parameter set, and implicit requirement tag set; The target tool is determined based on the intent structure, field pruning and normalization are performed on the parameter set, and a real-time resource snapshot is obtained; Calculate the dynamic potential difference and calibrate the spatial redundancy bias, combine the implicit demand mark set with tension resolution to generate the final tool request and invoke it; After a successful call, the candidate trajectory is stored and offline verified by the second language model before being written into the validated sample library. The new query calculates three types of contract hash values, performs fusion recall, contract comparison and semantic gatekeeping verification. If successful, it reuses the intent structure and tool request, and performs rights escalation and ranking based on behavioral data.

2. The target search method according to claim 1, characterized in that, The acquisition of natural language query, session context, and behavioral data, and the generation of schema-based intent recognition prompts based on business configuration, specifically includes: In response to user-triggered search requests, obtain natural language query statements, multi-turn dialogue context, and user behavior data including historical hotel browsing icons and favorite hotel icons within the current session; Synchronously retrieve the intent definition set, facility standard vocabulary, domain terminology, and scenario implicit requirement mapping rules corresponding to the current scenario from the business configuration library; After reading the intent definition set and the implicit requirement mapping rules of the scenario, the input pattern of the hotel search tool bound to each intent is obtained, the field name, enumeration value constraint and required attribute are extracted and transcribed into a natural language parameter description section. The natural language parameter description section is injected into the system prompt as a binding instruction, and contextual integration is performed by combining the facility standard vocabulary and domain terminology to generate schema-based intent recognition prompts.

3. The target search method according to claim 2, characterized in that, The construction of the implicit requirement inference chain, which involves inputting the first language model to generate an intent structure, a parameter set, and an implicit requirement tag set, specifically includes: Based on the implicit demand mapping rules of the scenario, and combined with the conversation context and behavioral data, semantic parsing of natural language queries is performed to infer the deep demands of users that are not explicitly expressed, and to construct an implicit demand inference chain that covers spatial distance tolerance, facility configuration preference, price range flexibility and itinerary planning constraints. The natural language query, conversation context, behavioral data, and implicit demand inference chain are assembled into a context, and under the format constraints of the schema-based intent recognition prompt words, they are input into the first language model for online inference and parameter extraction. Based on the reasoning results of the first language model, an intent structure and a set of structured parameters for specifying the retrieval target are generated, and a set of implicit demand tags is extracted from the structured output of the first language model. The set of implicit demand tags corresponds to the implicit demand inference chain.

4. The target search method according to claim 1, characterized in that, The process of determining the target tool based on the intent structure, performing field pruning and normalization on the parameter set, and obtaining a real-time resource snapshot specifically includes: The target hotel search tool is determined based on the intent tags in the intent structure. Field pruning, type normalization, and protected context field injection are performed on the structured parameter set according to the input pattern to match the parameter format with the tool contract. The implicit requirement tag set is then associated with the tool contract constraints index. Synchronously acquire real-time resource snapshots, which include housing inventory data from the central reservation system, real-time map traffic data, and spatial grid coordinate data; The parameter set, which has been encapsulated and formatted by the data layer, is associated with and pre-assembled with the spatial grid coordinates in the real-time resource snapshot to generate an initial tool request.

5. The target search method according to claim 4, characterized in that, The process of calculating the dynamic potential difference and calibrating the spatial redundancy bias, combined with the implicit demand marker set and tension resolution to generate the final tool request and invoke it, specifically includes: Based on the structured parameter set and real-time resource snapshot, the dynamic potential difference is calculated. Combined with spatial grid coordinate data and real-time map traffic data, spatial redundancy deviation caused by the inconsistency between straight-line distance and actual commuting time is identified and calibrated. Based on the travel planning constraints in the implicit demand mark set, check whether the search parameters requested by the initial tool conflict with the housing inventory data; if there is a conflict, combine facility configuration preferences and price range flexibility to perform tension reduction and correction, dynamically adjust the search boundary and budget fluctuation range, and generate tension reduction records; Based on the parameters after tension resolution and correction, a final tool request conforming to the tool contract is generated, the target hotel search tool is invoked, the business retrieval is performed, and the hotel room business execution results verified by the central reservation system are obtained.

6. The target search method according to claim 1, characterized in that, After a successful invocation, the candidate trajectory is stored and offline verified by the second language model before being written into the validated sample library. Specifically, this includes: When the target hotel search tool meets the preset success criteria, candidate trajectories are asynchronously collected and stored. The candidate trajectories include standardized user questions, intent structures, parameter structures, implicit demand marker sets, tension resolution records, tool names and parameter bodies, and session context. During the offline batch processing period, a second language model with higher reasoning ability than the first language model is used to re-execute intent recognition, parameter extraction and reassemble tool requests on candidate trajectories under the same schema-based intent recognition prompt words and input pattern constraints. The verification results of the second language model are compared with the candidate trajectory, and five levels of consistency checks are performed in sequence, including intent structure comparison, structured parameter set comparison, implicit requirement mark set comparison, tool request comparison, and tension resolution record comparison. Only when the verification results and the candidate trajectory are completely consistent in the above five levels will the candidate trajectory be promoted and written into the verified sample library.

7. The target search method according to claim 6, characterized in that, The new query calculates three types of contract hash values, specifically including: For newly arriving user queries, calculate the corresponding intent contract hash value, parameter contract hash value, and tool request contract hash value based on the intent structure, parameter structure, and tool request structure generated in the current session. Based on the verified sample library, a hybrid retrieval combining dense vector retrieval and lexical retrieval is performed, and a candidate retrieval result set is generated according to the fusion ranking strategy.

8. The target search method according to claim 7, characterized in that, The execution of fusion recall, contract comparison, and semantic gatekeeping verification, if successful, reuses the intent structure and tool request, and performs rights escalation and ranking based on behavioral data, specifically including: Three-level contract consistency comparison and semantic gatekeeping verification are performed sequentially on the candidate retrieval result set. The three-level contract consistency comparison includes the comparison of intent contract hash value, parameter contract hash value and tool request contract hash value. The semantic gatekeeping verification is performed based on embedding similarity or re-ranking model. If the three-level contract consistency comparison and semantic gatekeeper verification both pass, the corresponding historical intent structure and historical tool request in the verified sample library are reused, skipping the online reasoning and tool request assembly stage, and the target hotel search tool is called again based on the reused historical tool request to obtain the real-time hotel room business execution results. Before the reuse results are output, based on the behavioral data in the current user session context, the target hotels in the reuse results that belong to the user's historical browsing or favorites are identified and priority ranking is performed to display them with higher priority, and the final output results are generated.

9. A computing device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement a target search method as described in any one of claims 1-8.

10. A storage medium, characterized in that, The storage medium stores at least one computer program, which is loaded and executed by a processor to enable the computer to implement a target search method as described in any one of claims 1-8.

Images