Intelligent high-speed-oriented spatial semantic retrieval agent construction method

Abstract

The invention relates to an intelligent high-speed-oriented spatial semantic retrieval agent construction method. The method comprises the following steps: constructing an entity segmented word library based on multi-source high-speed traffic spatial information data; for each entity in the entity segmentation library, converting different source names and coordinates of the entities into vectors, and constructing a vector library; the big language model obtains user inquiry information, entity information is extracted based on a segmented word library, and an entity recognition candidate set is obtained; vector representation of entities is extracted from a vector library on the basis of the entity recognition candidate set, retrieval and reasoning of entity relations are conducted on the basis of the knowledge graph, and the entity recognition candidate set and information obtained from the vector library and the knowledge graph serve as background information of space retrieval; and converting the background information into a heterogeneous engine scheduling instruction set, and calling a dynamic execution routing graph of the multi-dimensional space query to obtain a retrieval result. By means of the method, the spatial information retrieval problem can be efficiently solved, ambiguity in entity recognition can be eliminated, and the complex spatial query process can be processed.

Description

Technical Field

[0001] This invention belongs to the field of digital economy and intelligent transportation technology, specifically relating to a method for constructing a spatial semantic retrieval intelligent agent for smart highways. Background Technology

[0002] With the rapid development of the high-speed rail economy and intelligent transportation technologies, spatial retrieval has important applications in intelligent highway management, operation, and monitoring. Especially against the backdrop of the national push for digital transformation of highways, users and managers have a need to quickly obtain static geographic information (such as the location of toll stations or service areas), and even expect to quickly obtain complex dynamic topological relationship information (such as the nearest service area, upstream hubs, etc.). However, current spatial retrieval technologies have not yet fully met these needs, particularly in terms of semantic understanding and the calculation of dynamic and complex topological relationships.

[0003] Currently used spatial retrieval algorithms have three obvious drawbacks:

[0004] 1. Semantic disconnect between querying and retrieval: Existing GIS systems rely on databases such as SQL / GeoJSON for spatial queries, requiring manual conversion of natural language into structured language executable by the database (e.g., "service areas along the way" corresponds to topological relationship query and service area category range query). However, semantic understanding based directly on large language models has limited semantic understanding capabilities, thus requiring high-quality corpora of proprietary entity names. Furthermore, the generated SQL may contain errors during the conversion process, leading to inefficiency in actual execution.

[0005] 2. Ambiguity in Entity Recognition: Current entity recognition algorithms suffer from ambiguity. For example, the question "Which part of the Nanjing Bridge is not congested?" can easily be misidentified as "Nanjing Bridge" or as two separate entities, "Nanjing" and "Bridge". However, the user's actual subconscious meaning, "the bridge in Nanjing", cannot be accurately identified. Furthermore, the lack of a verification mechanism for spatial entity retrieval conditions can lead to inaccurate entity recognition or loss of key information, further affecting retrieval results.

[0006] 3. Low spatial computing efficiency: For complex spatial information retrieval problems, such as "What other bridges are there in Jiangsu Province besides Taizhou Bridge?" or "What are the two nearest toll stations to Wuxi West Railway Station?", multiple calls to the spatial database are usually required, with response times exceeding 10 seconds. For large-scale datasets, the efficiency problem is even more serious, resulting in a poor user experience.

[0007] Due to the aforementioned shortcomings and corresponding technical bottlenecks, the existing solutions have a low success rate in high-speed management and intelligent customer service scenarios. More than 70% of complex queries still require manual intervention, which greatly limits the automation, informatization and intelligence of the system. Summary of the Invention

[0008] This invention aims to solve the problems existing in the prior art and provide a method for constructing intelligent spatial semantic retrieval agents for smart highways.

[0009] To achieve the above objectives, the present invention adopts the following technical solution:

[0010] A method for constructing a spatial semantic retrieval agent for intelligent high-speed rail, the method comprising:

[0011] An entity segmentation library is constructed based on multi-source high-speed traffic spatial information data, and a pre-segmentation device is built based on the constructed segmentation library;

[0012] For each entity in the entity segmentation library, its different source names and entity geographic coordinates are converted into vectors, and stored together with the encoded information of the entity coordinates in the vector library;

[0013] Construct a dynamic knowledge graph with a four-layer structure consisting of an entity layer, a relationship layer, a business rule layer, and a real-time road network status layer;

[0014] Configure the agent workflow to perform spatial retrieval tasks, including:

[0015] The large language model acquires user query information, calls the spatial retrieval agent, extracts entity information from the query information based on the pre-segmenter, and obtains an entity recognition candidate set; based on the entity recognition candidate set, it extracts the vector representation of the entity from the vector library, and simultaneously performs entity relationship retrieval and reasoning based on the knowledge graph; the entity recognition candidate set and the information obtained from the vector library and knowledge graph are used as background information for spatial retrieval.

[0016] By using a large language model combined with the background information and predefined high-speed traffic space rules, a heterogeneous engine scheduling instruction set is generated; the instruction set contains multiple computationally isolated basic instruction elements with execution engine affiliation tags, and each basic instruction element corresponds to a preset retrieval logic;

[0017] The instruction set is transformed into a dynamic execution routing graph for multi-dimensional space query. The basic instruction element is used as the intent root node to trigger the corresponding underlying physical engine to perform calculations and generate the final search results.

[0018] In some embodiments of the present invention, the multi-source high-speed traffic spatial information data includes at least spatial information data during construction and spatial information data during operation;

[0019] A credibility parameter is assigned to high-speed traffic spatial information data from different sources, and a fusion weight is constructed for the names of the same entity from different sources based on the number of semantic information fields contained in the entity and the credibility of the data source, which is used for priority ranking of entity names in the word segmentation library.

[0020] In some embodiments of the present invention, when the pre-segmenter extracts entity names, it marks their positions in the query information and records them as position codes of the corresponding entity names, which serve as common spatial feature parameters for subsequent entity relationship combination degree calculation.

[0021] In some embodiments of the present invention, the entity segmentation library is preprocessed and used for entity extraction, including:

[0022] Entity names are processed uniformly, and directional identifiers are standardized;

[0023] The final word frequency is calculated using a weighted average algorithm based on the frequency of the entity's appearance in different data sources.

[0024] Part-of-speech tagging based on entity type;

[0025] The preprocessed data is structured into triplet structures based on entity name, word frequency, and part of speech;

[0026] For the entity segmentation library with triple structure, starting from each position of the user query information, reverse matching is performed using a sliding window according to the preset maximum matching length.

[0027] In some embodiments of the present invention, the extraction of vector representations of entities from the vector library includes:

[0028] Spatial range filtering based on coordinate-based encoded information;

[0029] The distance range for filtering based on spatial range is used to filter matching vectors based on vector similarity calculation;

[0030] The search results are reordered based on relevance to obtain the final results.

[0031] In some embodiments of the present invention, the basic instruction elements include attribute retrieval, topology retrieval, range retrieval, path retrieval, and composite nested retrieval that defines combined instructions;

[0032] The preset topology search parameters include topology direction and driving direction.

[0033] The path retrieval is based on preset path types and driving direction parameters.

[0034] In some embodiments of the present invention, the dynamic execution routing graph includes:

[0035] Spatial topology operator nodes, as direct subordinate nodes of the intention root node, attach direction pointers to the incoming data;

[0036] Entity nodes, as the underlying leaf nodes under operator nodes, are used to store static identifiers, including entities.

[0037] Alternatively, dynamic state constraint nodes, as conditional branches of the intent root node, contain real-time traffic state parameters and are used by the physical execution layer for dynamic data filtering of the road network.

[0038] In some embodiments of the present invention, the method further includes constructing a three-layer index system for spatial indexing, including:

[0039] Semantic similarity index: Construct a graph index based on entity name vectors to perform semantic similarity retrieval;

[0040] Topology relation index: Constructs a relation vector based on road network connectivity for each entity to perform semantic retrieval of topology relations;

[0041] The comprehensive scoring index calculates entity scores by constructing a weighted model based on the similarity between query vectors and entity vectors, the entity's topological relationship score, and the entity's business rule matching degree. Retrieval is performed based on the scores. The entity's topological relationship score is obtained based on the entity's spatial distance and topological relationship type. The entity's spatial distance is calculated based on coordinate vectors.

[0042] In some embodiments of the present invention, the method further includes constructing a multi-level context storage architecture to decompose and store the session records generated by a single user query, and to retrieve these records when the user makes multiple queries, including:

[0043] Session-level context: formed based on a user's search history, storing the complete history of the user's session;

[0044] Entity-level context: Bound to session-level context, caches detailed entity information based on user retrieval history within the session-level context;

[0045] Relationship-level context: Bound to the session-level context, it records the spatial topological relationships between entities based on the user retrieval history of the session-level context;

[0046] State-level context: Stores real-time road network status information; the state-level context is shared information among multiple users and can be invoked as needed when any user queries it.

[0047] In some embodiments of the present invention, the method further includes: presetting a GIS action instruction protocol, outputting the search results using a nested action structure, wherein each action includes an action type and result data;

[0048] Different processing strategies are applied to different action types, including text display, map annotation, and integrated map display.

[0049] The present invention has the following beneficial effects:

[0050] (1) Based on high-speed traffic spatial information data from different sources, an entity segmentation library is constructed as the basis for user question identification, which can realize "breadth search" during matching and solve the semantic separation problem between query and retrieval; a vector database is constructed in combination with the segmentation library, and a dynamic high-speed knowledge graph is constructed, which combines entity name and entity relationship for joint disambiguation;

[0051] (2) Introduce data source credibility and weight for entity names to facilitate entity matching and meet business needs in different scenarios;

[0052] (3) The knowledge graph integrates the state layer and introduces real-time road network status (such as construction and closure) as dynamic constraints for graph reasoning.

[0053] (4) A spatial semantic intermediate state transformation rule for highway traffic is proposed, targeting the specific spatial characteristics of directed graph networks. Its encoding structure incorporates an abstract structure of road network topology features, reducing the dimensionality of problems along the route and upstream and downstream that traditional GIS needs to solve through complex latitude and longitude buffer calculations or multi-hop traversal of the map to the instruction set structure level; furthermore, the scheduling instruction set is parsed into a dynamic execution routing graph for multi-dimensional spatial queries, and different branch nodes of the routing graph serve as triggers that can be independently mounted to heterogeneous computing engines (such as vector databases, knowledge graphs, and relational databases), realizing hierarchical isolation and parallel scheduling computation under composite conditions, effectively solving the complex nested spatial query process.

[0054] (5) Design a four-layer dynamic context management architecture. In addition to simple chat records, the context is also divided into entity, relationship and state layers for storage. Based on the structured and layered approach, real-time information is selectively and dynamically added to the large model context window as background information for LLM to make decisions.

[0055] (6) When outputting data, a dedicated GIS action type protocol is defined so that the search results directly drive map layers and hardware devices (such as cameras) instead of just returning text. Attached Figure Description

[0056] Figure 1 This is a flowchart of the method of the present invention.

[0057] Figure 2 This is a sequence diagram of the interaction between spatial retrieval agents. Detailed Implementation

[0058] The technical solution of the present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0059] The large model involved in the embodiments refers to the Large Language Model (LLM), which can be implemented using existing open-source LLMs; the pre-trained model involved in the embodiments can be obtained by fine-tuning based on existing open-source embedding models.

[0060] The implementation plan will describe the technical solution in three main steps: knowledge graph construction and vector retrieval of basic spatial entities of highways, design and parsing of Heterogeneous Engine Instruction Set (HEIS) based on large model context, and research and application of spatial retrieval intelligent agents. The details are as follows:

[0061] A1 Knowledge graph construction and vector retrieval of basic entities in transportation space;

[0062] This step constructs a framework for entity definition and relationship extraction in the high-speed transportation domain through a dual-driven model of semantic knowledge extraction and computable road network topology relationships. It comprises three sub-steps, with the specific process including:

[0063] A1.1 A Method for Constructing and Extracting a High-Speed ​​Traffic Entity Word Segmentation Library Based on Multi-Source Data Fusion

[0064] This step involves constructing a proprietary entity name thesaurus based on specialized terminology in the high-speed transportation field, and pre-segmenting the spatial retrieval problem.

[0065] From a business scenario perspective, spatial retrieval mainly involves searching for various terms such as "gantry," "toll station," "service area," "mileage marker," "road line," "bridge," "camera," "province, city, district," and "road company." However, when users actually inquire, they don't use standard spatial entity names; they usually use abbreviations, alternative names, or older terms. Therefore, it's necessary to first extract the potential location information contained in the user's question and then further identify the entity names corresponding to this location information. Thus, constructing a dictionary of entity names specific to the highway transportation domain as the basis for identifying user questions is particularly important.

[0066] Spatial data sources for high-speed transportation mainly fall into two categories: spatial information data during construction and spatial information data during operation.

[0067] Spatial information data during construction refers to the data declared from the beginning of road planning and design to the implementation of the project, equipment installation, and construction completion. The data comes from CAD drawings, project lists, etc., and the latitude and longitude coordinates, names, and other attribute information of each facility are standardized and accurate.

[0068] Spatial information data during operation refers to the data declared from the start of road opening to daily operation and maintenance, accident handling, and repair. The data comes from various business systems (such as dispatching systems, video systems, road network status perception systems, etc.) and terminal devices (such as GPS devices, positioning devices, sensors, etc.). This information has rich semantic information (such as abbreviations, former names, and alternative names), but lacks standardization.

[0069] 1. Standard word segmentation library construction method

[0070] 1.1 Multi-source entity data fusion algorithm

[0071] The purpose of constructing the fusion algorithm is to determine the priority ranking of different data sources in the word segmentation library. The fusion weight is used to determine the priority of different data sources, with data sources with higher weights ranked first, thus prioritizing the selection of more reliable data sources when completing or deduplicating information.

[0072] Define data source weights method:

[0073]

[0074] in: Entity resource item The fusion weights; : Entity resource item; : Data source size during the construction period. Size refers to the number of semantic information fields included in this entity; : Runtime data source size; Total size of the data source; : Data source credibility coefficient (construction phase data weight), this weight ranges from [0,1], representing the credibility of the data source during the construction phase. Higher values ​​tend to indicate a data source during the construction phase; when... Lower values ​​tend to indicate runtime data sources.

[0075] 1.2 Word segmentation library construction method

[0076] The thesaurus will dynamically integrate data from multiple sources according to the structure of triples (entity name, attribute set, data source identifier). Taking a toll station as an example: [

[0078] {

[0079] Standard Entity Name: "Jiangsu Liuhe South Mainline Station", / / Construction Period Data

[0080] "Aliases": ["Liuhe Station", "Liuhe South Main Line Station"], / / Operational data

[0081] "Attributes": {

[0082] Type: Tollbooth

[0083] "Storage Number": "KXX+XXX",

[0084] "Latitude and longitude": [118.xxxx, 32.xxxxx],

[0085] "Administrative Divisions": ["Jiangsu Province", "Nanjing City", "Liuhe District"],

[0086] "Road": "G2503 Nanjing Ring Expressway"

[0087] "Company under Jurisdiction": "Company Name"

[0088] },

[0089] "Data source identifier": {

[0090] "Construction Option Weight": 0.8,

[0091] "Running Option Weight": 0.2,

[0092] Source: ["Engineering Design Drawings - CAD", "xx System"]

[0093] }

[0094] },

[0095] { ...

[0097] } ]

[0099] 2. Word segmentation methods for the problem

[0100] 2.1 Location Information Labeling Method

[0101] Using the word segmentation library built in section 1.2, the large model can extract entity names from user questions and mark their positions in sentences. While understanding semantic information, it can also make full use of the positional information of entity relationships, thereby improving the model's ability to reason about topological relationships between entities.

[0102] Define the entity information location encoding method:

[0103]

[0104] in:

[0105] Character position (0-based)

[0106] Sentence length

[0107] : Encoding bit length (usually b=4)

[0108] Location information annotation example:

[0109] {

[0110] Search: "Service areas near Wuxi West Railway Station"

[0111] "Word segmentation": [

[0112] {

[0113] Text: "Wuxi West Railway Station",

[0114] Type: Tollbooth

[0115] "Start position": 0,

[0116] "End position": 4,

[0117] " 0.95,

[0118] "Location code": 9

[0119] },

[0120] {

[0121] Text: "Service Area",

[0122] Type: Service Area

[0123] "Starting position": 6,

[0124] "End position": 9,

[0125] " 0.92,

[0126] "Location code": 16

[0127] } ]

[0129] }

[0130] Note: For ease of understanding, the code in the examples has been translated and adjusted.

[0131] The location encoding in the code converts the location encoding of the four characters "Wuxi West Station" into a value for storage. Different conversion methods can be used; in this example, addition conversion is used.

[0132] By comparing the position code differences between the two entities This can help determine potential relationships:

[0133] (Threshold): There is a potential strong correlation between entities;

[0134] The entities are far apart, indicating a potential weak correlation.

[0135] in Encode the location of entity 1. The location is encoded for entity 2.

[0136] 2.2 Word segmentation table loading and entity recognition candidate set

[0137] The word segmentation tables are dynamically loaded according to the road network layers: the route table corresponds to the road entity database, and the toll station table corresponds to the toll station entity database. In each entity database, standard entity names and aliases are used as candidate sets, but are prioritized according to weight and provided as background information. The specific steps are as follows:

[0138] 1. Vocabulary format conversion

[0139] The original word segmentation table (the word segmentation library constructed in section 1.2) is standardized according to a unified triplet structure (entity name, word frequency, part of speech) to ensure consistency in the format of word segmentation data from different sources. The conversion process includes:

[0140] Entity standardization: unify the processing of entity names, such as removing the "station" suffix and standardizing service area directional signs;

[0141] Term frequency calibration: The final term frequency is calculated using a weighted average algorithm based on the frequency of occurrence of entities in different data sources;

[0142] Part-of-speech tagging: Accurate part-of-speech tagging based on entity type (such as toll station, service area, road, etc.).

[0143] 2. Candidate Set Generation Method

[0144] Based on the standardized vocabulary, a sliding window algorithm is used to generate a candidate entity set:

[0145] Longest Match Strategy: Starting from each position in the user's query text, perform reverse matching according to the preset maximum matching length (e.g., 20 characters, i.e., the size of the sliding window), prioritizing the matching of longer entity names;

[0146] Part-of-speech filtering: Based on the query context, entities of specific part-of-speech types can be selectively filtered (e.g., only matching toll booths or service areas).

[0147] Location Encoding: A location encoding is generated for each matched entity for subsequent entity relationship analysis. The location encoding is calculated based on the character positions of the entity names identified in the user's original natural language query. When a name (e.g., 'Huai'an Station') corresponds to multiple standard entities in the word segmentation library (e.g., 'Huai'an East Station', 'Huai'an West Station'), these candidate standard entities all inherit the location encoding of the reference in the original query statement, serving as common spatial feature parameters for subsequent entity relationship assimilation calculation, without needing to rewrite or replace the original query statement. Entity relationship assimilation refers to the determination of entity relationship assimilation by using the location encoding obtained from the method of this invention. The location encoding represents the relative distance between the two entities in the same sentence, thereby recording the relative position of the entities in the semantic structure. For example, the location encoding is used to determine the distance (whether close) between the words "Wuxi West Station" and "service area" in the same sentence, thereby determining whether they have a modification relationship.

[0148] 3. Weighted ranking mechanism

[0149] The candidate set is ranked based on a multi-dimensional weight calculation model.

[0150] Word frequency weighting: Prioritize entities with higher word frequencies to reflect the importance of the entity in actual use;

[0151] Position weighting: The weighting is based on the importance of the entity's position in the query text, with higher weighting for the beginning of the sentence and keyword positions;

[0152] Type weighting: Set basic weights based on the importance of different entity types, such as mainline toll stations having a higher weight than general toll stations;

[0153] Data source weight: A comprehensive score is given by combining the credibility coefficients of data sources during the construction and operation phases.

[0154] 4. Candidate set post-processing

[0155] The initially generated candidate set is then optimized.

[0156] Entity boundary optimization: Combining contextual semantics and road network topology, correcting entities that may have boundary errors;

[0157] Directional information recognition: Automatically identifies and labels directional information related to entities (such as "direction", "up", "down" etc.);

[0158] City information annotation: Automatically supplement the city information based on the entity name and context;

[0159] Duplicate entity deduplication: Accurate deduplication is performed based on entity encoding and standardized names.

[0160] A1.2 Construction of Vector Knowledge Base and Dynamic Knowledge Graph in the High-Speed ​​Transportation Domain

[0161] Based on the high-speed transportation domain-specific entity name vocabulary constructed in Section A1.1, this section details the construction method of the vector knowledge base and the specific implementation method of the dynamic knowledge graph. Combined with practical vector retrieval code logic, it ensures the system's efficiency and accuracy. The vector knowledge base is used to retrieve spatial entity names contained in the question and match them using standard entity names. The dynamic knowledge graph models road network topology and dynamic state information to retrieve spatial relationships contained in the question and match them using standard entity relationships. In use, the agent, based on the pre-segmented candidate set, uses the vector knowledge base and knowledge graph to retrieve and reason about entity names, scopes, and entity relationships, and outputs background description information about the user's question.

[0162] 1. Vector Knowledge Base Construction Methods

[0163] 1.1 Entity Vectorization Processing

[0164] For high-speed traffic spatial data of millions of records, high-dimensional entity name vectors are generated using text embedding technology:

[0165] Entity name standardization: Standard entity names and aliases are preprocessed in a unified manner, including removing special characters, unifying encoding formats, and handling multilingual mixing.

[0166] Text embedding generation: Based on a pre-trained traffic-specific language model, entity names are converted into fixed-dimensional vector representations. The calculation formula is as follows:

[0167]

[0168] in: Entity vector representation; Standard entity name; : A collection of entity aliases; : Embedding function of pre-trained language model.

[0169] 1.2 Space Vector Optimization

[0170] To address geospatial retrieval needs, entity latitude and longitude coordinates are optimized using vectorization:

[0171] Coordinate vectorization: converting geographic latitude and longitude coordinates into low-dimensional spatial vector representations, preserving spatial location information while reducing dimensionality; coordinate vectors are used for calculating physical distances to entities in the subsequent comprehensive scoring index, and for topology calculations by the HEIS executor.

[0172] Geohash encoding: Geohash technology is used to encode coordinates, improving the efficiency of proximity queries. In subsequent spatial retrieval (before semantic retrieval), Geohash encoding is used for initial screening, reducing the amount of subsequent vector calculations.

[0173] 2. Dynamic Knowledge Graph Construction Methods

[0174] 2.1 Four-layer knowledge graph architecture

[0175] A dynamic high-speed knowledge graph is constructed based on a four-layer structure: basic entities, relationships, business rules, and real-time road network status.

[0176] Basic Entity Layer: Based on the standardized entity vocabulary constructed in Section A2.2, entity nodes and their attribute information are constructed;

[0177] Relationship layer: Based on the topology of the highway network, construct spatial relationships (such as upstream and downstream, adjacency, inclusion, etc.) and semantic relationships (such as same name, alias, etc.) between entities.

[0178] Business rules layer: Based on the business rules of highway operation and management, a rule library is formed, such as toll rules, road restriction rules, and service area service rules;

[0179] Real-time road network status layer: Connects to the road network sensing system to update road network status information in real time, such as the opening and closing status of toll stations, road traffic flow, accident information, construction status, etc.

[0180] 2.2 Knowledge Graph Dynamic Update Mechanism

[0181] Incremental data updates and version management ensure the dynamic updating of knowledge graph data and the traceability of historical records.

[0182] Incremental update: Based on event-driven, it realizes incremental updates of data, and automatically updates relevant nodes and relationships when the road network status changes;

[0183] Version management: It adopts a version control mechanism, retains historical status information, and supports backtracking queries along the time dimension.

[0184] 2.3 Relational Reasoning

[0185] Based on the constructed knowledge graph, the relational reasoning ability is optimized to add auxiliary information. This part can be achieved using existing methods:

[0186] Path reasoning: Graph-based path reasoning, such as "which toll stations are there on the way from A to B";

[0187] Transitivity: Reasoning that supports transitivity, such as "If A is adjacent to B, and B is adjacent to C, then A and C may have an indirect relationship";

[0188] Rule-based reasoning: Based on the business rule layer, it supports complex business logic reasoning.

[0189] 3.1 Multi-level index construction

[0190] A three-layer indexing system is constructed to support semantic retrieval needs at different granularities:

[0191] Semantic similarity index: Based on entity name vectors, an HNSW (Hierarchical Navigable SmallWorld) graph index is constructed to support fast semantic similarity retrieval, with particularly optimized retrieval performance for business keywords such as "nearby", "upstream", and "downstream".

[0192] Topology Relationship Index: Combining the static topology structure of the highway network, a relationship vector based on the network connectivity is constructed for each entity, supporting semantic retrieval of topology relationships;

[0193] Comprehensive Scoring Index: Based on a multi-factor scoring model, calculates the comprehensive relevance score of an entity.

[0194]

[0195] in:

[0196] : The overall score of entity e; Weighting coefficients for each factor; : The cosine similarity between the query vector and the entity vector; Topological relationship score of entities; : The degree of matching of the entity's business rules.

[0197] Topological relationship score here It is used to measure the strength of spatial relationships between entities and is calculated based on coordinate vectors.

[0198] in: Physical distance between entities; : The type of relationship between entities (such as upstream / downstream, adjacency, etc.); f(): A function that calculates a score based on distance and relationship type.

[0199] By constructing a multi-factor scoring model based on semantic similarity, coordinate proximity, topological reachability, and industry rule matching, different indicators can be adjusted in different scenarios. For example, command and dispatch focuses on industry rule matching, while customer service assistants focus on topological reachability.

[0200] A1.3 Spatial Retrieval Background Information Extraction Based on Semantic Understanding and Relational Reasoning

[0201] Based on the entity candidate set constructed in Section A1.1 and the vector knowledge base and dynamic knowledge graph constructed in Section A1.2, this section elaborates on the specific implementation method of spatial retrieval background information extraction, and combines the actual vector retrieval code logic to ensure the efficiency and accuracy of the system.

[0202] 1. Multi-source background information extraction method

[0203] 1.1 Semantic Retrieval from Vector Databases

[0204] Based on the user's query text, semantic similarity retrieval is performed using a vector knowledge base to obtain semantically related entities and information:

[0205] Query vector generation: The user query text is converted into a vector representation using an embedding function. The similarity between the query vector and the entity vector is calculated using cosine similarity. The search results are filtered based on the similarity threshold to obtain a set of search results.

[0206] The search results are re-ranked using the ReRanker model to further identify results with higher relevance.

[0207] 1.2 Knowledge Graph Relational Reasoning

[0208] Relationship reasoning is performed based on dynamic knowledge graphs to extract relationship information between entities:

[0209] Spatial Relationship Reasoning: Based on the topological structure of the graph, calculate the spatial relationship score between entities.

[0210]

[0211] in: :entity and Spatial relationship score; Distance between entities; : The type of relationship between entities; : Relationship score calculation function.

[0212] Semantic relation reasoning: Calculating the semantic association between entities based on graph-based semantic relations.

[0213]

[0214] in: :entity and Semantic relevance; Semantic similarity between entities; Co-occurrence frequency between entities; Semantic relevance calculation function.

[0215] 1.3 Dynamic Status Information Integration

[0216] Integrates real-time road network status information and provides dynamic background support:

[0217] Status Update: Dynamically update entity status information based on real-time data stream.

[0218]

[0219] in: :entity In time The state; : State update function; :time New data.

[0220] 2. Background Information Fusion and Optimization

[0221] 2.1 Multi-source information fusion

[0222] Background information from different data sources is fused. Here, background information refers to information obtained from the vector knowledge base and graph relationship reasoning in the previous step, including: extracted entity information highly relevant to the problem (entity name, entity code, latitude and longitude coordinates, road company, road direction, etc.), topological relationships of entities, entity types, etc. The fusion processing steps include:

[0223] (1) Deduplication is performed based on entity ID and standardized name;

[0224] (2) Information completion based on data source weights;

[0225]

[0226] in: :entity Complete information; The weight of the i-th data source; Entities in the i-th data source Information.

[0227] 2.2 Information Richness Optimization

[0228] Optimize the richness and coverage of background information, including:

[0229] (1) Expand relevant information based on the relationships between entities;

[0230] (2) Completing missing attributes based on statistical patterns:

[0231]

[0232] in: The complete attribute of entity e; Given entity e, the probability of attribute p occurring.

[0233] 3. Formatted output of background information

[0234] The extracted and optimized background information is output in a standardized format for use in large models.

[0235] JSON format encapsulation: Encapsulate the background information into a structured JSON format for easy parsing of large models;

[0236] Information classification and organization: Background information is organized according to categories such as entity information, relationship information, and status information;

[0237] Key information highlighting: Mark and highlight key information to make it easier for large models to focus on it;

[0238] Contextual integrity: Ensure that the background information of the output has good contextual integrity, which can support the understanding and reasoning of large models.

[0239] A2. Construction of a Spatial Semantic Structured Representation Model for Topological Network Topology Based on Retrieval Context Knowledge

[0240] To ensure efficient scheduling of spatial retrieval and efficient collaborative computing of heterogeneous data, this application defines the syntactic structure of a heterogeneous engine scheduling instruction set, transforming natural language intents into a heterogeneous engine scheduling instruction set, and driving the physical engine based on a dynamic execution routing graph of structured multidimensional spatial queries. This approach is not a synonym for existing database query languages ​​(such as SQL), but rather a structured intermediate representation method proposed for the specific spatial characteristics of directed graph networks on highways.

[0241] A2.1 Internal encoding of the Heterogeneous Engine Scheduling Instruction Set (HEIS) and the syntax structure of each instruction.

[0242] In terms of internal coding structure design, the heterogeneous engine scheduling instruction set abandons the traditional query language (such as SQL, GeoJSON) which uses "absolute spatial coordinates" or "relational table association" as its core expression method. Instead, it adopts a structured design approach of "topology direction engine + heterogeneous operator drive".

[0243] Based on the high-speed business logic, we abstract the spatial retrieval problem on highways into multi-dimensional actions with topological attributes, including attribute retrieval, topological retrieval, range retrieval, and relation retrieval. Traditional GIS queries are mostly based on absolute location (Euclidean space), while the representation model in this application is based on the directed graph topological space of highways (driving direction, upstream and downstream, connectivity), and encapsulates graph algorithm calls and direction tracking into a unified instruction set application logic:

[0244] 1. Attribute Query

[0245] Syntax structure:

[0246] attr_query: GET property_list OF entity_code

[0247] property_list: attr_field ("," attr_field)*

[0248] (Attribute retrieval command: retrieve attribute list belonging to entity identifier)

[0249] Attribute list: attribute field(", attribute field) *)

[0250] Example: Retrieve toll station name and mileage information

[0251] 2. Topology Query

[0252] Syntax structure:

[0253] relation_query: FIND entity_type topo_direction travel_direction? OFposition_spec index_spec?

[0254] topo_direction: UPSTREAM | DOWNSTREAM | ADJACENT

[0255] travel_direction: POSITIVE | NEGATIVE

[0256] position_spec: entity_code

[0257] index_spec: POSITION NUMBER | RANGE NUMBER TO NUMBER

[0258] coord: "(" NUMBER "," NUMBER ")"

[0259] (Topology relation command: Find entity type, topology direction, driving direction?, location description, index description?)

[0260] Topological direction: Upstream | Downstream | Adjacency

[0261] Driving direction: Forward | Reverse

[0262] Location Description: Entity Identifier

[0263] Index description: Position number | Range number to number

[0264] Coordinates: "("number", "number")")

[0265] Example: Find the nearest service area downstream from Nanjing.

[0266] 3. Range Query

[0267] Syntax structure:

[0268] category_query: QUERY entity_type WHERE condition travel_direction?

[0269] condition: condition_field EQUAL value -> eq_condition

[0270] | condition_field IN "(" value ("," value)* ")" -> in_condition

[0271] (Category query command: Query the driving direction of entities that meet the following conditions?)

[0272] Condition: Condition field equals set value -> Equality condition

[0273] | The condition field is contained in "(" set value (", set value) * ")" -> combined condition)

[0274] Example: Query all service areas within Jiangsu Province

[0275] 4. Path Query

[0276] Syntax structure:

[0277] path_query: FIND path_type FROM entity_code TO entity_code

[0278] path_type: SHORTEST | FASTEST | LONGEST | SAFEST | ECO

[0279] travel_direction: POSITIVE | NEGATIVE

[0280] (Path lookup command: Find the path type that starts at the entity identifier and ends at the entity identifier)

[0281] Route type: Shortest | Fastest | Longest | Safest | Most environmentally friendly

[0282] Driving direction: forward | reverse)

[0283] Example: Find the shortest path from toll station A to service area B.

[0284] 5. Compound nested search (Condition Query)

[0285] Syntax structure:

[0286] query: basic_query | combined_query

[0287] basic_query: attr_query | category_query | relation_query | path_query

[0288] combined_query: basic_query logic_op basic_query

[0289] | combined_query logic_op basic_query

[0290] | "(" combined_query ")"

[0291] logic_op: AND | OR | NOT / / Logical operators

[0292] (Query logic instructions: basic instructions | combined instructions)

[0293] Basic commands: Attribute search | Category search | Topology search | Path search

[0294] Combination Instructions: Basic Instructions, Logical Operators, Basic Instructions

[0295] | Combination Instructions, Logical Operators, Basic Instructions

[0296] | “(” combined instruction “)”

[0297] Logical operators: AND | OR | NOT (logical operators)

[0298] Example: Query all service areas within Jiangsu Province, including toll station names and mileage information for service areas named "Nanjing".

[0299] By defining four basic categories of questions and combining them with nested combination logic, complex questions about highway spatial retrieval can be answered. The design philosophy behind this syntax is that it doesn't simply rely on database code queries, but rather uses built-in primitives oriented towards road network topology constraints (such as topological direction and driving direction) to decouple the steps that originally relied on complex database code involving multi-hop graph traversal into a structured logic layer, which is then executed by different sub-physics engines.

[0300] The defined instruction set differs from the internal structural features of traditional similar scheduling techniques in the following ways:

[0301] 1. Natively built-in road network topology constraints (topology dimensionality reduction structure):

[0302] Traditional GIS spatial computing often requires complex latitude and longitude buffer scanning algorithms or large-scale multi-hop knowledge graph calculations when handling "along the route" or "downward direction". This application's scheduling instruction set provides a "dimensionality-reduced representation" of this calculation at the syntactic level. By setting specific "topological direction (e.g., upstream, downstream)" and "travel direction (e.g., forward, reverse)" dimension tuple parameters, the cumbersome geometric topology calculations are directly translated into lightweight direction pointer identifiers, providing a high-speed, efficient identification channel for backend routing and physics engine execution.

[0303] 2. Heterogeneous disassembly structure for composite operations (independent slot processing):

[0304] Traditional natural language recognition or query syntax typically extracts "flat slots" (e.g., sending an aggregate query to the database upon recognizing an entity and an operation instruction). This instruction set is designed as a "modular, isolated operation," where all intents involving complex retrieval (e.g., finding objects with specific attributes within a specific range) are orchestrated into isolated "basic instruction elements" (e.g., attribute retrieval, topology retrieval). These instruction elements come with their own execution engine affixation tags, allowing for seamless transformation into distribution nodes in the routing graph.

[0305] 3. Convergence (intermediate state transformation) of natural language fuzziness into deterministic computation channels:

[0306] User queries in fuzzy natural language are difficult for conventional databases to understand directly. This instruction set provides an intermediate protocol; it is not simply a query language, but a set of control instructions encompassing "conditions, scope, direction, and aggregation logic." This process of transforming unstructured semantic intent into highly condensed logical operators not only eliminates the "language illusion" of large models from affecting the final call, but also ensures deterministic delivery of the final scheduling to the underlying physical nodes through strict instruction set constraints.

[0307] A2.2 Dynamic Execution Routing Graph and Operator-Level Logical Scheduling Tree Calculation for Multidimensional Spatial Queries

[0308] After generating the scheduling instruction set for the large model construction, the lexical and syntax parsing unit parses the instruction set to generate a dynamic execution routing graph for the corresponding multi-dimensional space query, thereby realizing the transformation from logical declaration to physical execution pipeline.

[0309] The “lexical and syntactic parsing unit” described here is an improvement on the classic Abstract Syntax Tree (AST) parser: it can not only logically divide the scheduling instruction set into interrelated node symbols (constructing a dependency parent-child tree of the instruction level), but also further combine the retrieval intent to bind specific executor registration information to each node.

[0310] The aforementioned "dynamic execution routing graph for multidimensional spatial queries" is essentially a deeply customized abstract syntax tree (AST) with spatial relationships and execution environment constraints. It still represents the program's computational structure through different nodes, but compared to traditional ASTs, it has the following characteristics in node definition and structural arrangement:

[0311] 1. Multi-dimensional constraint slot mounting structure: The dynamically executed execution routing graph of the parsed multi-dimensional spatial query has a strong business constraint hierarchy. Unlike ordinary AST nodes built by traditional code (usually syntax declarations or operators), its graph structure contains four types of custom node groups with specific business flow functions:

[0312] 1) Intent Root Node: As the entry point and highest control point of the parse tree, it corresponds to the basic instruction elements set above (such as attribute search instructions, range search instructions, etc.). Its function is to receive the user's higher-level search intent and distribute the data results aggregated downstream to the corresponding preset underlying search engine (such as knowledge graph or spatial database).

[0313] 2) Topology Operator Node: As a direct subordinate control node of the intent root node, it carries and differentiates the computational features of the highway network, internalizing spatial relationship computational requirements such as "driving direction (Positive / Negative)" and "topological direction (Upstream / Downstream)". When data flows through this node, a direction pointer is attached to it for subsequent accurate graph inference and matching.

[0314] 3) Entity Node: As the underlying leaf node and the basis for parameter passing, it is mounted under the operator node. It is specifically used to store static identifiers such as the start and end entities identified and segmented from the large model and the POI name. When performing calculations, it passes the basic entity number (ID) to the calculation domain of the branch.

[0315] 4) State Constraint Node: A modifier node used for post-processing filtering and evaluation, incorporating real-time traffic state parameters (such as construction congestion, speed limits). It is typically attached to the conditional branch of the intent root node and used for dynamic filtering of road network data at the physical execution layer.

[0316] In terms of parsing, execution, and flow processing, after the user's search intent is orchestrated and a dynamic execution routing graph of mutual attachments is constructed, the system adopts a top-down distribution and scheduling mechanism as the execution blueprint for each independent search branch: First, the execution engine enters from the intent root node (i.e., where each basic instruction element is located, such as attribute search and range search), and determines the underlying physical search engine type corresponding to the current search request based on the instruction element (e.g., whether to allocate to basic operations based on the graph database or spatial search based on the vector library). Subsequently, the execution conditions are obtained by traversing downwards along the branch of the intent node: the spatial topology operator node is read, and its internalized topological constraints and driving direction are extracted; then, the entity node attached to it is read, and the corresponding start and end entity coordinates or identifiers (IDs) are obtained, which are used as necessary parameters for the underlying computational domain of each retrieval branch; if there are dynamic state constraint nodes on the branch, they are also brought in with the real-time traffic status of the road network as environmental filtering conditions; finally, the multi-dimensional computational parameters distributed in the branches of each level of nodes are uniformly assembled by the intent root node of the branch into a structured physical query request, which is then sent to the matching graph inference or vector retrieval engine. Compared with the traditional flat intent recognition slot extraction, this structure explicitly solidifies its distribution rules on each custom computational node containing topological information, establishing data flow dependency constraints.

[0317] 2. Decoupling of Logical Declarations and Physical Execution, and Dynamic Routing Mechanism: The scheduling instruction set represents the logical declaration of retrieval requests. After reading its structured text, the system-level interpreter performs hierarchical isolation and decomposition of nested instructions (such as the `combined_query` node). For example, attribute query branches are routed to traditional relational databases (executing SQL queries), upstream / downstream and connectivity topology reasoning branches are routed to knowledge graphs (executing graph traversal computation), and fuzzy range computation is routed to vector databases. This dynamic isolation and parallel scheduling strategy provides a standard data fusion pipeline protocol between heterogeneous retrieval engines.

[0318] 3. Dynamic Operator Injection Mechanism: This parsing structure possesses extremely strong pluggable extensibility. When new dimensions of business requirements are added to the application scenario, it is only necessary to register the extended computation operator type (such as highway bridge features) within the interpreter, and the routing graph calling framework with the same structure can be used to carry out the underlying changes.

[0319] During the retrieval process, the retrieval execution module sequentially calls different distribution paths according to the routing graph node dependencies:

[0320] Execution route distribution: The retrieval module traverses the dynamic execution route graph of the above multi-dimensional space query and establishes context transmission rules between tasks.

[0321] Dynamic trigger execution: In a heterogeneous retrieval environment, the basic instruction elements that are separated and arranged and carry engine affiliation tags serve as scheduling trigger points to trigger the corresponding underlying physical engines (such as attribute calculation engines, topology reasoning engines, or vector matching engines) to carry out specific calculation processes.

[0322] Result synthesis and assembly: The node range results after the graph reasoning is pre-filtered are passed into the vector space for post-filtering, or sorting and formal transformation are completed through relational post-processing, and finally a data set in a unified standard format is returned.

[0323] A3 Construction of Intelligent Agents Based on Spatial Retrieval

[0324] Simply having a Heterogeneous Engine Scheduling Instruction Set (HEIS), a dynamic execution routing graph for multidimensional spatial queries, and an executor is insufficient to complete a full spatial retrieval task. It is necessary to design and construct an agent that implements specific definitions for context, input parameters, and output parameters, ensuring that: 1. The large model can discover available spatial retrieval agents; 2. The large model knows how to use spatial retrieval agents; 3. The large model knows how to use the results of spatial retrieval agents; 4. The system page knows how to use the agent's output for standardized display. This is divided into the following four parts:

[0325] A3.1 Spatial Retrieval Intelligent Agent Design Process

[0326] In designing intelligent agents, it's necessary to consider the boundaries and design of the agent in conjunction with the traffic scenario and existing business system interaction processes. This ensures seamless integration of the agent with existing business systems, enabling AI-driven upgrades to existing systems. For spatial retrieval agents, several key points to consider include:

[0327] 1. Interaction methods of spatial retrieval agents

[0328] The core of spatial retrieval is basic spatial data, and the results must include spatial geographic location information. Therefore, the most direct interaction method is map interaction. Building upon map interaction, since highway services involve five aspects—construction, management, maintenance, operation, and service—it also requires dynamically displaying highway service-related data. For example, after retrieving camera geographic information, the map should not only display the camera's location and icon but also support opening the corresponding camera's video—that is, command interaction. Text interaction is suitable for everyday assistant chat modes, while voice interaction is suitable for large-screen demonstration modes.

[0329] Therefore, the interaction methods include text interaction, voice interaction, map interaction, and command interaction.

[0330] 2. Context Management of Spatial Retrieval Agents

[0331] During agent interaction, the agent, as a backend service, involves multiple interactions with the business system. If it is merely called by the business system as an independent tool, problems arise: for example, in the first round of interaction, the user asks for the location of service area A. The spatial retrieval agent retrieves the basic geographic information of service area A through attribute queries. In the second round, the user requests to view cameras near service area A. The agent again first uses attribute queries to obtain the basic geographic information of service area A, and then uses range queries to retrieve the cameras near service area A.

[0332] Therefore, a standard context entry point needs to be designed for intelligent agents so that intelligent agent tools can be seamlessly integrated with business systems.

[0333] 3. Information transmission modes of space intelligent agents

[0334] Since the mainstream intelligent agent interaction methods currently used in the market are Model Context Protocol (MCP) and A2A (Agent-to-Agent), and considering that spatial intelligent agents are more tool-side oriented, we chose to use the MCP standard protocol for construction.

[0335] Therefore, the spatial retrieval agent is designed as follows:

[0336] The spatial retrieval agent is built on the Model Context Protocol (MCP) standard protocol, ensuring that large models can automatically discover and identify available agent tools.

[0337] The specific implementation includes:

[0338] 1. Standardized Service Registration:

[0339] The agent server is built using the FastMCP framework, and services are registered via the standard MCP protocol. Based on the standard interface of the MCP protocol, large models can automatically scan and identify available tools.

[0340] Define clear service names and descriptions, such as "Spatial Retrieval Intelligent Agent Query Service for the Highway Industry". Support multiple MCP transmission methods (stdio, streamable-http, etc.) for easy deployment and invocation in different environments.

[0341] 2. Tool metadata definition:

[0342] Each tool is provided with detailed descriptive information. For example, the entity information spatial retrieval tool (search_spatial_entity_info) is explicitly described as "performing spatial retrieval based on the spatial geographic information of highways." Through semantic matching of tool names and descriptive information, the large model can understand the function and applicable scenarios of each tool.

[0343] Define standardized parameter modules Mode The Pydantic base model is used to ensure the normalization of the parameter structure.

[0344] Provide detailed descriptions of the parameters, such as the context parameter being described as "context content related to the SBDS spatial retrieval agent", and the query parameter being described as "the user's latest question".

[0345] A3.2 Dynamic Context Management Mechanism for Intelligent Agents

[0346] Context management for spatial retrieval agents is crucial for ensuring the coherence and intelligence of multi-turn dialogues. Based on the MCP protocol, an innovative dynamic context management mechanism was designed:

[0347] 1. Multi-level context storage architecture

[0348] Session-level context: Based on a user's search history, it stores the complete history of the user's session, including query intent, entity relationships, search results, etc., and has personalized features.

[0349] Entity-level context: Bound to session-level context, taking into account the spatiotemporal locality of a specific user, and caching detailed information for specific entities, such as service area attributes, camera status, etc.

[0350] Relational context: Bound to the session context, it records the spatial topological relationships between entities and supports relationship reasoning such as "nearby" and "upstream".

[0351] State-level context: Saves real-time road network status information, such as traffic flow and construction status, and shares it with all users.

[0352] The advantage of this approach is that the system, through its multi-level context storage architecture, supports both user-level personalized storage and global-level general information extraction. Furthermore, based on event-driven mechanisms, it enables incremental data updates, ensuring the timeliness and accuracy of contextual information.

[0353] The following is an example of a data structure in a multi-level context storage architecture:

[0354] {

[0355] "Session-level context": {

[0356] "Session ID": "Session_20241207_001",

[0357] User ID: "user_12345",

[0358] Start Time: 2024-12-07T13:55:00Z

[0359] "Query History": [

[0360] {

[0361] "time stamp ": "2024-12-07T13:55:10Z",

[0362] "Query Intent": "Query service area information for the G2 Beijing-Shanghai Expressway (Beijing to Shanghai direction)"

[0363] "Reality body ["G2 Beijing-Shanghai Expressway", "Beijing", "Shanghai", "Service Area"],

[0364] "Relationship": ["Directional Relationship", "Containment Relationship"],

[0365] "Query results": {

[0366] Service Areas: ["Pingqiao Service Area", "Gaoyou Service Area", "Jiangdu Service Area"],

[0367] Total: 3

[0368] }

[0369] },

[0370] {

[0371] "time stamp ": "2024-12-07T13:56:30Z",

[0372] Search History: "Search for cameras near Gaoyou Service Area",

[0373] "Reality body ["Gaoyou Service Area", "Camera"],

[0374] "Relationship": ["Nearby Relationships"],

[0375] Search results: {

[0376] "Camera": ["CAM_G2_001", "CAM_G2_002"],

[0377] "Distance": [500, 800]

[0378] }

[0379] }

[0380] ],

[0381] Current Focus: Facilities around Gaoyou Service Area

[0382] },

[0383] "Entity-level context": {

[0384] "G2 Beijing-Shanghai Expressway": {

[0385] Entity type: "Highway",

[0386] "belongs to sex hs": {

[0387] "road generation code ": "G2",

[0388] "Road name say Beijing-Shanghai Expressway

[0389] "Starting point": "Beijing"

[0390] Destination: Shanghai

[0391] "Chief of Staff": 1262,

[0392] "Lane number 4,

[0393] Speed ​​limit: 120

[0394] },

[0395] Last updated: 2024-12-07T13:50:00Z

[0396] "Cache lifetime" between 3600

[0397] },

[0398] "Gaoyou Service Area": ​​{

[0399] "Entity Type": "Service Area"

[0400] "belongs to sex ": {

[0401] "Service Area Code": "SA_G2_001",

[0402] Name: Gaoyou Service Area

[0403] "Location": {

[0404] Precision: 116.5678

[0405] Latitude: 39.7890

[0406] },

[0407] "set up Shi ["Gas station", "Restaurant", "Restroom", "Parking lot"],

[0408] Capacity: 200

[0409] Business Hours: 24 hours

[0410] },

[0411] Last updated: 2024-12-07T13:55:15Z

[0412] "Cache lifetime" between 1800

[0413] },

[0414] "CAM_G2_001": {

[0415] Entity type: "Camera",

[0416] "Attributes": {

[0417] "Camera ID": "CAM_G2_001",

[0418] "Location": {

[0419] Longitude: 116.5680

[0420] Latitude: 39.7885

[0421] },

[0422] Direction: South

[0423] Status: Online

[0424] Resolution: 1080p

[0425] },

[0426] Last updated: 2024-12-07T13:56:35Z

[0427] "Cache lifetime" between 300

[0428] }

[0429] },

[0430] "Relationship-level context": {

[0431] Spatial Relationships: {

[0432] "Gaoyou Service Area": ​​{

[0433] "Nearby entities": [

[0434] {

[0435] "Entity": "CAM_G2_001",

[0436] "Relationship": "Nearby",

[0437] Distance: 500

[0438] Direction: Southeast

[0439] },

[0440] {

[0441] "Entity": "CAM_G2_002",

[0442] "Relationship": "Nearby",

[0443] Distance: 800

[0444] Direction: Southwest

[0445] }

[0446] ],

[0447] "Upstream Reality" body ": [

[0448] {

[0449] Entity: Pingqiao Service Area

[0450] "Relationship": "Upstream",

[0451] Distance: 45

[0452] Trip Duration: 30

[0453] }

[0454] ],

[0455] Downstream body ": [

[0456] {

[0457] "Entity": "Jiangdu Service Area"

[0458] "Relationship": "Downstream",

[0459] Distance: 80

[0460] Trip Duration: 50

[0461] } ]

[0463] }

[0464] },

[0465] Topology picture ": {

[0466] " point ["Beijing", "Pingqiao Service Area", "Gaoyou Service Area", "Jiangdu Service Area", "Shanghai"],

[0467] "side": [

[0468] {"From": "Beijing", "To": "Pingqiao Service Area", "Distance": 25, "Type": "Expressway"},

[0469] {"From": "Pingqiao Service Area", "To": "Gaoyou Service Area", "Distance": 45, "Type": "Expressway"},

[0470] {"From": "Gaoyou Service Area", "To": "Jiangdu Service Area", "Distance": 80, "Type": "Expressway"},

[0471] {"From": "Jiangdu Service Area", "To": "Shanghai", "Distance": 1112, "Type": "Expressway"} ]

[0473] }

[0474] },

[0475] "State-level context": {

[0476] "Road Network Status": {

[0477] "G2 Beijing-Shanghai Expressway": {

[0478] "Traffic flow": {

[0479] Current capacity: 1200

[0480] Average speed Spend 85,

[0481] Congestion Level: "Smooth Traffic"

[0482] Update time: 2024-12-07T13:55:00Z

[0483] },

[0484] Construction Status state ": [

[0485] {

[0486] "Road Section": "G2_K25-K30",

[0487] Type: Road Maintenance

[0488] "Start Time": "2024-12-07T08:00:00Z",

[0489] End Time: 2024-12-07T18:00:00Z

[0490] Impact: Single lane closure

[0491] }

[0492] ],

[0493] Weather conditions: {

[0494] Status: Sunny

[0495] Temperature: 15

[0496] Visibility: 10

[0497] }

[0498] }

[0499] },

[0500] "Reality body state": {

[0501] "CAM_G2_001": {

[0502] Status: Online

[0503] "Last Event Time": "2024-12-07T13:56:30Z",

[0504] "picture picture Quality: "Good"

[0505] },

[0506] "Majuqiao Service Area": ​​{

[0507] Available parking spaces: 45

[0508] "Available fuel": "Sufficient"

[0509] Last updated: 2024-12-07T13:55:20Z

[0510] }

[0511] }

[0512] }

[0513] }

[0514] The context is compressed using existing methods and associated with a physics engine. This embodiment employs attention-based context compression and graph neural network-based relational reasoning to automatically identify entity relationships within the context.

[0515] A3.3 Multimodal Interaction Methods

[0516] The intelligent agent in this embodiment adopts multimodal interaction, including multimodal input, output, and switching between modes. Its functions can be implemented using existing methods, as follows:

[0517] 1. Multimodal input processing:

[0518] Text input: Employs a BERT-based semantic understanding model to support intent recognition for natural language queries;

[0519] Voice input: Integrated ASR system, supports real-time speech-to-text conversion, and combines voiceprint recognition for user authentication;

[0520] Map interaction: Based on GIS coordinate parsing, it supports semantic understanding of map operations such as clicking, dragging, and zooming;

[0521] Command interaction: Defines a standardized command syntax and supports operation commands such as "Open camera A".

[0522] 2. Multimodal output generation:

[0523] Text output: Generates natural language descriptions based on search results, supporting multilingual output;

[0524] Voice output: Integrated TTS system, supports voice broadcast of search results;

[0525] Map annotation: Automatically generates geographic annotation layers, supporting visualizations such as heatmaps and route planning;

[0526] Command execution: Supports direct calls to business system interfaces, such as opening video surveillance and starting navigation.

[0527] 3. Intelligent switching mechanism between modes:

[0528] Based on user behavior analysis and scene recognition, the system automatically recommends the optimal interaction method.

[0529] Supports the fusion processing of multimodal inputs, such as "camera at this location on the map" (gesture + voice).

[0530] It provides a unified modality conversion interface to ensure seamless switching between different interaction methods.

[0531] A3.4 Standardized Design of Intelligent Agent User Interface

[0532] 1. To enable large models to correctly utilize spatial retrieval agents, standardized interface specifications and parameter systems were designed:

[0533] Unified parameter interface design:

[0534] It uses structured API parameter definitions (APIParams) that include the required context and query parameters.

[0535] 2. Standardized invocation process:

[0536] Large models access entity information space via the Model Context (MCP) protocol. So tool;

[0537] The tool integrates OmniSSS services to handle the entire process of vector retrieval, knowledge graph reasoning, instruction set parsing, and operator-level logic scheduling and execution in a unified manner. It supports asynchronous call mode to improve response efficiency.

[0538] A3.5 Standardization of Agent Result Output Format

[0539] To enable large models to correctly understand and utilize the agent's output, this embodiment designs a structured output format and action instruction system:

[0540] 1. Standardized output structure:

[0541] It uses a unified JSON format for output, including core fields such as error information and result data. The result data adopts a nested action structure, supports multiple types of operation instructions, and each action contains action type (action_type) and result data (result), which facilitates classification and processing.

[0542] 2. Action instruction classification system:

[0543] Action type = 1: Query summary response, a natural language summary generated by the large model;

[0544] Action type = 2: Camera retrieval result (single result);

[0545] Action type = 3: Camera retrieval results (batch results);

[0546] Action type = 4: Toll station information retrieval results;

[0547] By classifying types, large models can adopt different processing strategies for different types of results.

[0548] 3. Standardize the results data:

[0549] Each type of result data adopts a unified field naming convention, including core information such as resource code, resource name, and geographic coordinates; it supports explicit identification of data types, such as camera type (eqp_camera), toll station type (station), etc.

[0550] A3.6 Standardized Display Mechanism for System Pages

[0551] To ensure that the system page can correctly parse and display the output results of the intelligent agent, this embodiment establishes a complete standardized display mechanism:

[0552] 1. Front-end display adaptation:

[0553] The front-end page renders different types of display components based on the action type:

[0554] The result of action type=1 is used for text display in the dialog interface; the results of action type=3 and action type=4 are used for map annotation and list display, supporting direct map integration display of geographic coordinate data.

[0555] 2. Data visualization support:

[0556] It provides a standardized geographic coordinate format, supporting direct integration with GIS systems; the structured data format facilitates statistical analysis and chart display on the front end; and it supports paginated display and filtering functions for batch data.

[0557] 3. Ensure consistency in presentation:

[0558] Standardized field naming and data structures ensure data consistency across different page components; responsive design adapts to the display needs of different terminal devices; and a unified style specification ensures visual consistency of the user interface.

[0559] Through the above standardized design, the spatial retrieval agent has achieved a complete closed loop from discovery, use, result processing to display, ensuring that large models and system pages can interact with the agent efficiently and accurately.

Claims

1. A method for constructing a spatial semantic retrieval agent for intelligent high-speed rail, characterized in that, The method includes: An entity segmentation library is constructed based on multi-source high-speed traffic spatial information data, and a pre-segmentation device is built based on the constructed segmentation library; For each entity in the entity segmentation library, its different source names and entity geographic coordinates are converted into vectors, and stored together with the encoded information of the entity coordinates in the vector library; Construct a dynamic knowledge graph with a four-layer structure consisting of an entity layer, a relationship layer, a business rule layer, and a real-time road network status layer; Configure the agent workflow to perform spatial retrieval tasks, including: The large language model acquires user query information, calls the spatial retrieval agent, extracts entity information from the query information based on the pre-segmenter, and obtains an entity recognition candidate set; based on the entity recognition candidate set, it extracts the vector representation of the entity from the vector library, and simultaneously performs entity relationship retrieval and reasoning based on the knowledge graph; the entity recognition candidate set and the information obtained from the vector library and knowledge graph are used as background information for spatial retrieval. By using a large language model combined with the background information and predefined high-speed traffic space rules, a heterogeneous engine scheduling instruction set is generated; the instruction set contains multiple computationally isolated basic instruction elements with execution engine affiliation tags, and each basic instruction element corresponds to a preset retrieval logic; The instruction set is transformed into a dynamic execution routing graph for multi-dimensional space query. The basic instruction element is used as the intent root node to trigger the corresponding underlying physical engine to perform calculations and generate the final search results.

2. The method according to claim 1, characterized in that, The multi-source high-speed traffic spatial information data includes at least spatial information data during the construction period and spatial information data during the operation period; A credibility parameter is assigned to high-speed traffic spatial information data from different sources, and a fusion weight is constructed for the names of the same entity from different sources based on the number of semantic information fields contained in the entity and the credibility of the data source, which is used for priority ranking of entity names in the word segmentation library.

3. The method according to claim 1, characterized in that, When extracting entity names, the pre-segmenter marks their positions in the query information and records them as the position codes of the corresponding entity names, which serve as common spatial feature parameters for subsequent entity relationship combination degree calculation.

4. The method according to claim 1, characterized in that, The entity segmentation library, after preprocessing, is used for entity extraction, including: Entity names are processed uniformly, and directional identifiers are standardized; The final word frequency is calculated using a weighted average algorithm based on the frequency of the entity's appearance in different data sources. Part-of-speech tagging based on entity type; The preprocessed data is structured into triplet structures based on entity name, word frequency, and part of speech; For the entity segmentation library with triple structure, starting from each position of the user query information, reverse matching is performed using a sliding window according to the preset maximum matching length.

5. The method according to claim 1, characterized in that, The extraction of vector representations of entities from the vector library includes: Spatial range filtering based on coordinate-based encoded information; The distance range for filtering based on spatial range is used to filter matching vectors based on vector similarity calculation; The search results are reordered based on relevance to obtain the final results.

6. The method according to claim 1, characterized in that, The basic instruction elements include attribute retrieval, topology retrieval, range retrieval, path retrieval, and composite nested retrieval that defines combined instructions; The preset topology search parameters include topology direction and driving direction. The path retrieval is based on preset path types and driving direction parameters.

7. The method according to claim 1, characterized in that, The dynamic execution routing graph includes: Spatial topology operator nodes, as direct subordinate nodes of the intention root node, attach direction pointers to the incoming data; Entity nodes, as the underlying leaf nodes under operator nodes, are used to store static identifiers, including entities. Alternatively, dynamic state constraint nodes, as conditional branches of the intent root node, contain real-time traffic state parameters and are used by the physical execution layer for dynamic data filtering of the road network.

8. The method according to claim 1, characterized in that, The method also includes constructing a three-layer index system for spatial indexing, including: Semantic similarity index: Construct a graph index based on entity name vectors to perform semantic similarity retrieval; Topology relation index: Constructs a relation vector based on road network connectivity for each entity to perform semantic retrieval of topology relations; The comprehensive scoring index calculates entity scores by constructing a weighted model based on the similarity between query vectors and entity vectors, the entity's topological relationship score, and the entity's business rule matching degree. Retrieval is performed based on the scores. The entity's topological relationship score is obtained based on the entity's spatial distance and topological relationship type. The entity's spatial distance is calculated based on coordinate vectors.

9. The method according to claim 1, characterized in that, The method further includes constructing a multi-level context storage architecture to decompose and store the session records generated by a single user query, and to retrieve these records when the user makes multiple queries, including: Session-level context: formed based on a user's search history, storing the complete history of the user's session; Entity-level context: Bound to session-level context, caches detailed entity information based on user retrieval history within the session-level context; Relationship-level context: Bound to the session-level context, it records the spatial topological relationships between entities based on the user retrieval history of the session-level context; State-level context: Stores real-time road network status information; the state-level context is shared information among multiple users and can be invoked as needed when any user queries it.

10. The method according to claim 1, characterized in that, The method also includes a preset GIS action command protocol, which outputs the search results using a nested action structure, with each action containing an action type and result data; Different processing strategies are applied to different action types; This includes text display, map annotation, and integrated map display.

Images