Metro signal operation and maintenance strategy generation method and system based on large model and vector-atlas dual channel knowledge enhancement

Abstract

The application discloses a subway signal operation and maintenance strategy generation method and system based on a large model and vector-atlas dual-path knowledge enhancement, and the method comprises the following steps: acquiring fault registration data and performing data cleaning and structured processing, constructing a fault knowledge graph and establishing a vector semantic index; determining the intention type after the user question is classified by intention and corrected by a rule patch, adaptively allocating the retrieval weight of the vector retrieval channel and the graph retrieval channel, and performing dual-path hybrid retrieval; sorting the retrieval results according to the intention type by using a differentiated fusion strategy; loading an external prompt template, inputting the fusion results into a local large language model to generate an operation and maintenance strategy; when the retrieval results are empty, automatically switching to a reasoning mode, and guiding the large language model to give suggestions based on general operation and maintenance knowledge. Through adaptive weight allocation, atlas-vector dual-path fusion and dual-mode switching, the method can accurately generate an operation and maintenance strategy, and improve fault disposal efficiency and decision quality.

Description

Technical Field

[0001] This invention belongs to the field of intelligent operation and maintenance technology of metro signaling, and in particular relates to a method and system for generating metro signaling operation and maintenance strategies based on large model and vector-graph dual-path knowledge enhancement. Background Technology

[0002] The metro signaling system is the core control system of urban rail transit, and its operational status directly affects train operation safety and efficiency. With the continuous increase in metro line mileage and the growing complexity of equipment systems, various faults inevitably occur during operation in the ATP / ATO subsystem, interlocking subsystem, axle counting subsystem, track circuit subsystem, ATS subsystem, and various communication subsystems. After a fault occurs, maintenance engineers need to quickly find similar historical fault cases, refer to existing handling solutions and troubleshooting experience, in order to shorten fault response time and repair time, and ensure train operation safety. Therefore, establishing a metro signaling fault knowledge base and realizing the intelligent generation of maintenance strategies based on historical experience and real-time reasoning is of great significance for improving the maintenance efficiency and fault handling level of the metro signaling system.

[0003] With the development of large language models and Retrieval-Augmented Generation (RAG) technologies, knowledge-based intelligent question-answering systems are widely used in industrial operations and maintenance. These systems typically first perform semantic retrieval on the user's question, recalling relevant documents from a knowledge base, and then provide the retrieval results as context to the large language model to generate an answer. However, in practical applications of subway signaling operations and maintenance, due to the highly structured nature of signaling fault data, the complex relationships between equipment entities (such as multi-level associations between lines, stations, equipment types, and fault modes), and the strong cross-subsystem linkages, conventional single-vector retrieval schemes are insufficient to meet the diverse retrieval needs of various operations and maintenance questions. Specifically, signaling engineers raise a variety of questions, including queries for solutions to "how to handle a fault in a certain signaling equipment on a certain line," statistical analyses of "fault rankings of various lines" and "average repair time for a certain fault type," and multi-hop related queries such as "which stations have experienced both turnout and track circuit faults simultaneously." Different types of questions have significantly different requirements for retrieval strategies, while existing systems usually adopt a uniform retrieval and answer strategy, resulting in inconsistent retrieval hit rates and strategy generation quality for different types of questions.

[0004] In existing technologies, signal fault knowledge acquisition typically employs keyword-based full-text retrieval, vector similarity-based semantic retrieval, or direct generation based on large language models. While these methods can meet retrieval needs to some extent, they still have the following shortcomings: First, although single vector retrieval can capture natural language semantic similarity, it cannot effectively utilize the structured relationships and hierarchical statistical information between lines, stations, and fault types in signal fault data. Second, while knowledge graph retrieval excels at structured queries and association analysis, it has weak semantic understanding capabilities in natural language and struggles to handle colloquial or non-standard operational questions. Third, existing systems use a uniform retrieval strategy for all user questions, failing to adaptively adjust the weight allocation between vector retrieval and knowledge graph retrieval channels based on the question intent type. Fourth, intent classification mainly relies on simple rule matching, resulting in insufficient accuracy when handling boundary issues and complex expressions. Fifth, when there are no matching cases in the knowledge base, the system usually returns empty results or low-quality answers directly, lacking the ability to supplement reasoning based on general operational knowledge from large language models.

[0005] Therefore, there is an urgent need for a metro signal maintenance strategy generation method that can adaptively adjust the dual-path retrieval strategy according to the intent type of the maintenance question, integrate the advantages of vector semantic retrieval and knowledge graph structured query, and drive the maintenance strategy generation by a local large language model. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for generating metro signal operation and maintenance strategies based on large model and vector-graph dual-path knowledge enhancement, in order to solve the problems of existing signal operation and maintenance knowledge systems having a single retrieval strategy, being unable to adaptively adjust the weight allocation of vector retrieval and graph retrieval according to the problem intent, and lacking the ability to supplement reasoning with large language models.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a method for generating metro signaling operation and maintenance strategies based on large model and vector-graph dual-path knowledge enhancement, comprising the following steps:

[0008] S1, acquire subway signal fault registration data, perform data cleaning and structuring processing on the fault registration data, construct a fault knowledge graph and establish a vector semantic index;

[0009] S2, obtain the user's input natural language operation and maintenance question, classify the question by intent through a rule classifier, and obtain preliminary intent type and signal device entity recognition results;

[0010] S3, The preliminary intent type is corrected by the rule patching module to obtain the corrected intent type;

[0011] S4. Based on the corrected intent type, adaptively allocate the retrieval weights and retrieval quantity of the vector retrieval channel and the graph retrieval channel, perform dual-path hybrid retrieval, and obtain vector retrieval results and graph retrieval results;

[0012] S5. Based on the intent type, select the corresponding fusion strategy to fuse and sort the vector retrieval results and the graph retrieval results to obtain the fused retrieval results;

[0013] S6. Load the corresponding prompt template according to the intent type, use the fusion retrieval result as context to construct prompt information according to the prompt template, input it into the local large language model, and generate subway signal operation and maintenance strategy text.

[0014] Furthermore, in step S1, constructing the fault knowledge graph includes: extracting entities such as line, region type, location, and fault type from the fault registration data as knowledge graph nodes, and establishing associations with the fault event as the central node and the line, fault type, and location; the knowledge graph is stored in a graph database, and the graph database is the Neo4j graph database.

[0015] Furthermore, in step S1, establishing a vector semantic index includes: concatenating each fault record into a retrieval text according to a preset text template, wherein the retrieval text at least includes the fields of line, specialty, fault type, location, fault phenomenon, fault cause, and handling process; encoding the retrieval text into a normalized vector using a pre-trained language model, and constructing a vector index based on inner product search, wherein the vector index is a FAISS index.

[0016] Furthermore, in step S2, the preliminary intent type includes at least five types: handling solution query, statistical analysis, multi-hop association query, open operation and maintenance Q&A, and classification judgment; the rule classifier classifies intents based on the keyword signals contained in the question, and the keyword signals include factual signal words, statistical signal words, multi-hop association signal words, and classification judgment signal words.

[0017] Furthermore, in step S3, the correction operation of the rule patching module includes:

[0018] When the question contains factual keywords but the initial intent type is not a solution query, the intent type will be changed to a solution query.

[0019] When the question contains statistical keywords but the initial intent type is neither a solution query nor a statistical analysis, the intent type will be corrected to statistical analysis.

[0020] When the question contains cross-category keywords or meets the preset cross-sentence regular expression pattern, and two or more fault type entities are identified, the intent type will be modified to a multi-hop related query.

[0021] When the specific intent type cannot be identified but the line entity and fault type entity have been identified, the intent type will be corrected to a solution query.

[0022] Furthermore, in step S4, the intent adaptive weight allocation is performed according to a preset weight mapping table, which defines the vector retrieval weight, graph retrieval weight, vector retrieval quantity, and graph retrieval quantity corresponding to each intent type; wherein:

[0023] The weight of graph retrieval for querying disposal solutions is greater than that of vector retrieval.

[0024] Vector retrieval with statistical analysis intent has zero weight, and graph retrieval is used entirely.

[0025] Graph retrieval has a greater weight than vector retrieval for multi-hop related query intents.

[0026] The vector retrieval weight for open operation and maintenance Q&A intent is greater than the graph retrieval weight.

[0027] Furthermore, in step S4, the graph retrieval constructs different structured query statements based on the intent type, including:

[0028] For the intent to query handling solutions, construct a graph query that uses fault type and / or line as filtering conditions and sorts the handling solutions in descending order of frequency of occurrence;

[0029] For statistical analysis purposes, a graph query is constructed with statistical dimensions as grouping conditions and the number of fault events as aggregation indicators. The statistical dimensions include grouping by line and grouping by fault type.

[0030] For multi-hop related query intents, construct cross-fault type same location query to find common locations where two or more different fault types occur simultaneously;

[0031] For the purpose of open operation and maintenance Q&A, construct a general graph query with fault type, line and / or profession as filtering conditions.

[0032] Furthermore, in step S5, the fusion strategy is selected based on the differences in intent type:

[0033] For queries regarding treatment plans, a graph-first fusion strategy is adopted, placing graph retrieval results at the top and adding non-repeating entries from vector retrieval results to the bottom, and then uniformly normalizing the scores.

[0034] For statistical analysis purposes, a graph-exclusive fusion strategy is adopted, using only the graph retrieval results and not fusing the vector retrieval results;

[0035] For multi-hop related query intents, a graph-first fusion strategy is adopted, which merges the non-repeating entries in the graph retrieval results and vector retrieval results and then performs unified normalized scoring.

[0036] For open operation and maintenance Q&A intents, a weighted reciprocal sorting fusion algorithm is used, and the calculation formula is as follows:

[0037]

[0038] in, For vector retrieval weights, The weights for map retrieval are k, which is a preset constant. and These represent the ranking of the entry in the vector search results and the graph search results, respectively.

[0039] Furthermore, step S6 also includes a zero-match inference mode: when the fusion search result is empty, an inference guidance context is automatically constructed. The inference guidance context includes device type information and prompt information, which guides the large language model to generate inference strategy suggestions based on general signal operation and maintenance knowledge, and marks the inference identifier in the generated text to distinguish between the standard strategy generated based on the search case and the reference strategy generated based on inference.

[0040] In step S6, each intent type corresponds to an independent prompt template file. The prompt template file is placed externally in the system running directory in the form of a text file. It is read from the text file in real time each time a prompt message is built, so as to support hot updates of prompt templates without restarting the system. When the prompt template file is missing, the built-in default prompt template is automatically used as a fallback.

[0041] Based on the same inventive concept, this invention also proposes a metro signaling operation and maintenance strategy generation system based on large model and vector-graph dual-path knowledge enhancement for implementing the above method, comprising:

[0042] The data preprocessing and knowledge base construction module is used to acquire subway signal fault registration data, perform data cleaning and structuring, construct a fault knowledge graph, and establish a vector semantic index.

[0043] The intent classification module is used to acquire natural language operation and maintenance questions input by users, classify the intents through a rule classifier, and correct the initial intent types through a rule patching module to obtain the corrected intent types and signal device entity recognition results.

[0044] The dual-path hybrid retrieval module is used to adaptively allocate the retrieval weights and retrieval quantities of the vector retrieval channel and the graph retrieval channel according to the corrected intent type, and to perform dual-path hybrid retrieval.

[0045] The fusion and ranking module is used to select the corresponding fusion strategy based on the intent type to fuse and rank the vector retrieval results and the graph retrieval results.

[0046] The strategy generation module is used to load the corresponding prompt template according to the intent type, use the fused search results as context to construct prompt information, input the local large language model to generate subway signal operation and maintenance strategy text, and automatically switch to inference mode when the search results are empty.

[0047] Compared with the prior art, the present invention has the following beneficial effects:

[0048] (1) This invention uses a rule-based classification and vector KNN combined intent classification and rule patching correction mechanism to accurately classify signal operation and maintenance questions into five intent types: handling plan query, statistical analysis, multi-hop association query, open operation and maintenance question and answer, and classification judgment. This solves the problem that the existing system's unified retrieval strategy cannot adapt to diverse operation and maintenance questions, and can provide differentiated knowledge enhancement and strategy generation methods for different types of questions.

[0049] (2) The present invention uses an intention-adaptive weight allocation strategy to automatically adjust the weight ratio and retrieval quantity of vector retrieval and graph retrieval according to the intention type, so that the dual-path knowledge enhancement strategy for different intention types is automatically optimized: in the disposal solution query, the structured association and frequency statistics capabilities of the knowledge graph are given priority; in the open operation and maintenance question answering, the semantic generalization capability of vector retrieval is given priority; and in the statistical analysis, the aggregation and calculation capabilities of the knowledge graph are fully relied upon.

[0050] (3) This invention integrates vector semantic retrieval with knowledge graph structured query, and makes full use of the semantic generalization advantage of vector retrieval and the precise association and statistical advantage of knowledge graph retrieval. It can not only handle colloquial and non-standard natural language operation and maintenance questions, but also make full use of the structured entity relationships and multi-dimensional aggregated information in signal fault data to form a complementary and enhanced knowledge acquisition capability.

[0051] (4) This invention uses an externalized, hot-updateable prompt template management mechanism to store system prompt templates and five types of intent-specific prompt templates as independent text files. This allows maintenance personnel to adjust the strategy generation behavior of the large language model in real time without restarting the system, and automatically downgrade to use built-in default values ​​when template files are missing, thereby improving the system's operational flexibility and continuous service capabilities.

[0052] (5) This invention automatically switches to the reasoning strategy generation mode based on general signal operation and maintenance knowledge of large language model when there are no matching cases in the knowledge base through the zero-match reasoning mode, and clearly marks the reasoning identifier in the generated text, so as to ensure the traceability and reliability of the operation and maintenance strategy output. Attached Figure Description

[0053] Figure 1 The overall flowchart of the metro signal operation and maintenance strategy generation method based on large model and vector-graph dual-path knowledge enhancement provided in the embodiments of the present invention;

[0054] Figure 2 A flowchart of the offline knowledge base construction phase provided in this embodiment of the invention;

[0055] Figure 3 This is a schematic diagram of the system architecture for the online operation and maintenance strategy generation stage provided in an embodiment of the present invention;

[0056] Figure 4 A flowchart of rule-vector joint intent classification provided for embodiments of the present invention;

[0057] Figure 5 This is a flowchart of the intent-adaptive dual-path hybrid retrieval process provided in an embodiment of the present invention;

[0058] Figure 6 A flowchart for selecting a fusion sorting strategy provided in an embodiment of the present invention;

[0059] Figure 7 The flowchart illustrates the strategy generation and reasoning pattern provided in this embodiment of the invention. Detailed Implementation

[0060] This invention proposes a method for generating subway signaling operation and maintenance strategies based on large-scale models and vector-graph dual-path knowledge enhancement, comprising the following steps:

[0061] S1. Obtain subway signal fault registration data, perform data cleaning and structuring processing on the fault registration data, construct a fault knowledge graph and establish a vector semantic index.

[0062] Specifically, historical fault registration data is obtained from the subway signal fault registration system. This fault registration data is stored in Excel spreadsheet format. The xlrd library of the Python programming language is used to read each worksheet of the spreadsheet file, automatically detecting the header row containing the "serial number" column, and parsing the data starting from that row. The fault registration data includes at least the fields of fault date, line, specialty, fault type, location, fault phenomenon, fault cause, handling process, fault level, and repair time.

[0063] Data cleaning includes: automatically identifying and skipping header rows to extract valid fault record rows; performing structured parsing of the location field by delimiter to split it into four fields: line, area type, specific location, and direction; performing prefix cleaning on the fault cause and handling process to remove redundant marker text; merging fault phenomenon texts from multiple sources, prioritizing fault phenomena recorded in work orders; and standardizing time and numerical fields.

[0064] Constructing a fault knowledge graph includes: extracting entity nodes from cleaned fault registration data. These entity node types include line nodes, zone type nodes, location nodes, fault type nodes, and fault event nodes. Centering each fault event node, connections are established to the corresponding line node via OCCURRED_ON_LINE edges, to the fault type node via IS_TYPE edges, and to the location node via AT_LOCATION edges. Simultaneously, BELONGS_TO_LINE subordinate edges are established between location nodes and line nodes, and HAS_ZONE_TYPE subordinate edges are established between location nodes and zone type nodes. Uniqueness constraints are created for line nodes, zone type nodes, location nodes, and fault type nodes. Regular indexes are created for the date, specialty, and status fields of fault event nodes to accelerate queries. Finally, the entity nodes and their corresponding edges are imported into a Neo4j graph database for batch storage.

[0065] The process of establishing a vector semantic index includes: concatenating each fault record into a retrieval text according to a preset text template, with the template format being: [Line][Specialty] Fault Type | Location: Specific Location | Phenomenon: Fault Phenomenon Text | Cause: Fault Cause Text | Handling: Handling Process Text; encoding the retrieval text into 1024-dimensional normalized vectors in batches of 256 using the BGE-large-zh-v1.5 pre-trained language model; constructing the FAISS IndexFlatIP vector index, adding all normalized vectors to the index, and calculating semantic retrieval equivalent to cosine similarity using the inner product of the normalized vectors; exporting the vector index as a binary file, and serializing the metadata into a binary file for storage, the metadata including fields such as fault number, date, line, specialty, fault type, location, region type, fault phenomenon, fault cause, handling plan, and repair time.

[0066] S2, obtain the user's input natural language operation and maintenance question, and classify the question by intent using a rule classifier to obtain preliminary intent type and signal device entity recognition results.

[0067] Specifically, the intent types include at least five types: factual, statistical analysis, multi-hop association query, open QA (open maintenance Q&A), and taxonomy. The rule classifier predefines multiple keyword signals, including:

[0068] Factual signal words include "how to handle", "what to do", "how to solve", "handling method", "handling method", "how to solve", "how to handle", "solution", "how to repair", "handling plan", "solution method", and "handling measures";

[0069] Statistical signal words include "most", "least", "average", "statistics", "ranking", "frequency", "how many times", "trend", "percentage", "proportion", "summary", "total", "distribution", "top", "ranking", "several times", "several types", "several categories", "quantity", "number of times", "frequency", "how many kinds";

[0070] Multi-hop association signal words include "which", "list", "compare", "associate", "multiple", "occur simultaneously", "all appear", "intersect", and "common";

[0071] Classification judgment signal words include "whether it belongs to", "what it belongs to", "belongs to", "classification", "whether it counts", and "is it".

[0072] The signal equipment entity identification includes: matching the question with a predefined set of line names to identify line entities; matching the question with a predefined fault type keyword mapping table, sorting them according to keyword length priority to identify fault type entities; and matching the question with a predefined professional category to identify professional entities.

[0073] Furthermore, the intent classification can complement the vector KNN classifier. This vector KNN classifier constructs the FAISS IndexFlatIP intent classification index by encoding 24 labeled question classes into normalized vectors using a pre-trained language model. During classification, it retrieves the K most similar labeled questions to the input question and performs weighted voting to map the 24 subcategories into five intent types. When the vector KNN classifier is available, it is preferentially used for initial classification, followed by correction by the rule patching module; when the vector KNN classifier is unavailable, the enhanced rule classifier independently completes the intent classification.

[0074] S3, the preliminary intent type is corrected by the rule patching module to obtain the corrected intent type.

[0075] Specifically, the rule patching module includes a set of intent correction rules used to correct classification biases in the rule classifier regarding boundary issues and complex sentence structures. The correction rules include:

[0076] Patch Rule 1: When the question contains factual keywords, but the initial intent type is not a solution query, the intent type will be changed to a solution query, and the confidence level will be set to 0.90 or higher;

[0077] Patch Rule 2: When the question contains statistical keywords (such as "average", "statistics", "ranking", "summary", "total", "percentage", "proportion", "distribution"), and the initial intent type is not a solution query or statistical analysis, the intent type will be corrected to statistical analysis, and the confidence level will be set to 0.90 or higher.

[0078] Patch Rule 3: When a question contains ranking keywords (such as "most", "least", "highest", "lowest", "most frequent"), and the initial intent type is neither a solution query nor a statistical analysis, the intent type will be changed to statistical analysis.

[0079] Patch Rule 4: When the question contains cross-type keywords (such as "appear at the same time", "all appear", "occur at the same time") or simultaneously satisfies the regular expression matching patterns of "both X and Y" and "both X and Y", and the entity identifies two or more fault type entities, the intent type will be corrected to a multi-hop related query.

[0080] Patch Rule 5: When the specific intent type cannot be identified, but the line entity and fault type entity have been identified, the intent type will be corrected to a solution query.

[0081] S4. Based on the corrected intent type, adaptively allocate the retrieval weights and retrieval quantities of the vector retrieval channel and the graph retrieval channel, and perform dual-path hybrid retrieval.

[0082] Specifically, an intent-adaptive weight mapping table is pre-established, configuring corresponding vector retrieval weight Vw, graph retrieval weight Gw, vector retrieval quantity Vk, and graph retrieval quantity Gk for each intent type. In one embodiment of the invention, the weight mapping table is configured as follows:

[0083] Intended purpose of treatment plan query: Vw=0.35, Gw=0.65, Vk=3, Gk=5, spectral priority;

[0084] Multi-hop association query intent: Vw=0.20, Gw=0.80, Vk=2, Gk=8, priority given to salient graphs;

[0085] Statistical analysis intent: Vw=0.00, Gw=1.00, Vk=0, Gk=10, exclusive spectrum;

[0086] Open operation and maintenance Q&A intent: Vw=0.65, Gw=0.35, Vk=5, Gk=3, vector priority;

[0087] Classification and judgment intention: Vw=0.50, Gw=0.50, Vk=3, Gk=3, dual-path balance.

[0088] During vector retrieval, the maintenance question is encoded into a normalized vector using the pre-trained language model, and the top-Vk results are retrieved from the vector index based on inner product similarity. During graph retrieval, differentiated Cypher query statements are constructed based on the intent type.

[0089] For the intent to query the handling plan, construct a query statement with fault type and / or line as the filtering condition, match the line nodes connected by the OCCURRED_ON_LINE relationship and the fault type nodes connected by the IS_TYPE relationship of the fault event nodes, and optionally connect the location nodes by the AT_LOCATION relationship, filter the records where the handling plan is not empty, and sort them in descending order by the frequency of occurrence of the handling plan.

[0090] For statistical analysis purposes, construct a grouped aggregation query statement based on the statistical dimensions indicated in the question. When the statistical dimension is grouped by line, group by line name to count the number of fault events and average repair time for each line, and collect a list of fault types and example handling solutions for that line, sorted in descending order by the number of fault events. When the statistical dimension is grouped by fault type, group by fault type name to count the number of fault events and average repair time for each fault type, and collect a list of lines involving that fault type and example handling solutions, sorted in descending order by the number of fault events.

[0091] For multi-hop related query intents, when two or more fault types are identified, construct a cross-fault type same location query statement: first match all fault events of the first type of fault and their occurrence location, then match the fault events of the second type of fault in the same location set, aggregate and count the number of the two types of fault events at each location, exclude intermediate nodes whose location names are in pure number format, and sort in descending order of the total number of fault events.

[0092] For the open operation and maintenance Q&A intent, construct a general query statement with fault type, line and / or specialty as optional filtering conditions, and sort in descending order by date.

[0093] S5. Select the corresponding fusion strategy according to the intent type to fuse and sort the vector retrieval results and the graph retrieval results to obtain the fused retrieval results.

[0094] Specifically, differentiated fusion strategies are designed for different intent types:

[0095] For queries regarding treatment plans, a graph-first fusion strategy is adopted: Gk graph search results are placed at the beginning; Vk vector search results are traversed, and if the fault number of a vector search result does not appear in the fault number set of the graph search results, it is appended to the end of the results list; the merged results list is then uniformly normalized and scored using the following formula:

[0096] NormalizedScore(i) = 0.1 + 0.9 × (rawScore(i) - minScore) / (maxScore - minScore)

[0097] Where rawScore(i) is the original score of entry i. The graph results are assigned decreasing scores in descending order of frequency, and the vector results are assigned decreasing scores in descending order of similarity. minScore and maxScore are the minimum and maximum values ​​of the original scores of all entries, respectively. When maxScore equals minScore, the normalized score of all entries is set to 1.0.

[0098] For statistical analysis purposes, a graph-exclusive fusion strategy is adopted: only graph retrieval results are used, vector retrieval results are not fused, and the graph retrieval results are directly normalized and scored before being returned.

[0099] For multi-hop related query intents, a graph-first fusion strategy is adopted: first, the graph retrieval results are normalized and scored, and then the entries in the vector retrieval results that do not overlap with the graph results are normalized and scored before being added.

[0100] For open operation and maintenance question-and-answer intents and classification judgment intents, the weighted reciprocal rank fusion algorithm (RRF) is used. This algorithm calculates the fusion score for each entry according to the following formula:

[0101]

[0102] in, For vector retrieval weights, The graph retrieval weights are defined by k, a preset constant of 60. `rank_vec` represents the rank of an entry in the vector retrieval results (starting from 0), and `rank_graph` represents the rank of an entry in the graph retrieval results (starting from 0). For entries appearing only in the vector retrieval results, `rank_graph` is the maximum rank value plus one; for entries appearing only in the graph retrieval results, `rank_vec` is the maximum rank value plus one. Entries are sorted from highest to lowest by fusion score, and the top-K entries are selected as the fusion retrieval results.

[0103] S6. Load the corresponding prompt template according to the intent type, use the fusion retrieval result as context to construct prompt information according to the prompt template, input it into the local large language model, and generate subway signal operation and maintenance strategy text.

[0104] Specifically, each intent type corresponds to a separate prompt template file, including a system prompt template (system.txt) and intent-specific prompt templates (factual.txt, statistical.txt, multi_hop.txt, open_qa.txt, and taxonomy.txt). These prompt template files are externally located in the system's running directory as text files and are read in real-time each time this step is executed, supporting hot updates of prompt templates without requiring a system restart. If the text file is missing, the built-in default prompt template is automatically used to ensure uninterrupted service.

[0105] The process of constructing the prompt information is as follows: read the system prompt template and the intent-specific prompt template corresponding to the intent type from the prompt template file; convert each record in the fusion search results into context text, which at least includes the fields of line, fault type, location, fault phenomenon, fault cause, and solution; replace the {question} placeholders and {context} placeholders in the intent-specific prompt template with maintenance questions and context text, respectively; and concatenate the system prompt template with the filled intent-specific prompt template to form the complete prompt information.

[0106] The local large language model is a pre-trained language model deployed locally, preferably the Qwen3-4B model. It sends prompt information to the model service via an HTTP POST request and receives the operation and maintenance strategy text returned by the model. Request parameters include a maximum of 1024 generated tokens, a temperature of 0.3, and a Top-p sampling value of 0.9. When the large language model call times out (exceeding 300 seconds) or returns an error, the system automatically reverts to the template strategy generation mode, organizing the search results into structured operation and maintenance strategy text according to a predefined template format for output.

[0107] In one embodiment of the present invention, step S6 further includes a zero-match reasoning mode: when the fusion search result is empty, a reasoning guidance context is automatically constructed. The reasoning guidance context includes: explanatory text declaring that the knowledge base search result is empty, a device type description generated based on the signal device type information extracted from the question, and instruction text guiding the large language model to reason based on general signal operation and maintenance knowledge. The reasoning strategy text generated by the large language model must begin with a preset reasoning identifier to allow the user to clearly distinguish between the standard operation and maintenance strategy generated based on the search case and the reference strategy generated based on general knowledge reasoning.

[0108] The technical solution of the present invention will be further described below with reference to the accompanying drawings. It should be understood that the following embodiments are only used to illustrate the present invention and are not intended to limit the scope of protection of the present invention.

[0109] Example 1

[0110] like Figure 1 As shown in the figure, this embodiment provides a method for generating subway signaling operation and maintenance strategies based on large-scale model and vector-graph dual-path knowledge enhancement. The method consists of two stages: an offline knowledge base construction stage and an online strategy generation stage.

[0111] like Figure 2 As shown, the offline knowledge base construction phase includes:

[0112] Step S1-1, Data Acquisition and Conversion. In this embodiment, signal fault registration data is stored in an Excel spreadsheet file (.xls format). The xlrd library is used to read the contents of each worksheet in the spreadsheet file, automatically detecting the header row containing the "serial number" column, and parsing the data starting from that row. All rows in the spreadsheet are traversed row by row. Date type cells are converted to standard date and time string format, while other type cells retain their original values, and each row is written to a UTF-8 encoded CSV file. The fault registration data includes 20 fields: serial number, date, line type, specialty, fault type, location, reported fault phenomenon, work order fault phenomenon, fault level, fault source, fault report time, on-site processing time, response time, fault cause, processing procedure, fault end time, repair time, fault status, delay status, and delay index.

[0113] Step S1-2, Data Cleaning and Structured Processing. Read the CSV file, skipping the metadata rows before the header row, and use the header row as the DataFrame column names. Perform data cleaning according to the following rules: Delete invalid rows where the serial number column is empty or the serial number column value is not purely numeric; parse the location column into segments according to the delimiter, and extract the four fields of line, area type, specific location, and direction in sequence (for example, the location text "Line 3-Station-Tianyuan West Road" is parsed as line "Line 3", area type "Station", specific location "Tianyuan West Road", and direction is empty); perform prefix cleaning on the fault cause column, removing redundant prefixes such as "Custom cause:" and "Fault cause:"; perform prefix cleaning on the processing column, removing redundant prefixes such as "Custom solution:" and "Processing:"; merge fault phenomena: prioritize the text in the "Work Order Fault Phenomenon" column, and if it is empty, use the text in the "Report Fault Phenomenon" column, removing redundant prefixes such as "Fault Phenomenon:"; convert the date column to date and time type, and convert the maintenance duration and response time to numeric type.

[0114] Steps S1-3: Construct a fault knowledge graph. Import the cleaned data into the Neo4j graph database. First, create graph database constraints and indexes: create unique constraints for Line labels, Zone type labels, Location labels, Fault type labels, and the fault_id field of the Fault Event label. Create regular indexes for the date, professional, and status fields of the Fault Event label to speed up queries. Then, import the data in batches according to the following node types and relationship types:

[0115] Line node: Extracts duplicate values ​​from the line column, performs a MERGE operation to create nodes in batches of 500, and the node attribute is name;

[0116] ZoneType node: Created by extracting duplicate values ​​from the parsed zone type field; the node attribute is name.

[0117] Location node: Created by extracting duplicate values ​​from the parsed specific location field; the node attribute is name.

[0118] Fault Type Node: Created by extracting duplicate values ​​from the fault type column; the node attribute is name.

[0119] Fault Event Node: A node is created for each fault record. The node attributes include fault_id (taken from the sequence number), date, line, professional, zone_type, location_name, direction, phenomenon (taken from the merged fault phenomenon), cause (taken from the cleaned fault cause), solution (taken from the cleaned processing), repair_hours, response_hours, status, and source;

[0120] Create the OCCURRED_ON_LINE relationship from the fault event node to the line node;

[0121] Create the IS_TYPE relationship between fault event nodes and fault type nodes;

[0122] Create the AT_LOCATION relationship from the fault event node to the location node (when the location is not empty);

[0123] Create a BELONGS_TO_LINE relationship from the location node to the line node (when both the location and line are not empty);

[0124] Create a HAS_ZONE_TYPE relationship from the location node to the region type node (when both the location and region type are not empty).

[0125] Steps S1-4: Establish a vector semantic index. Concatenate each fault record into retrieval text according to a preset template. The template format is: [Line][Specialty] Fault Type | Location: Specific Location | Phenomenon: Fault Phenomenon Text | Cause: Fault Cause Text | Handling: Handling Process Text. For excessively long fault phenomenon and handling process texts, truncate them to a preset length (truncate the first 200 characters for phenomenon, the first 100 characters for cause, and the first 200 characters for handling). Use the BGE-large-zh-v1.5 pre-trained language model to encode the retrieval text into 1024-dimensional normalized vectors in batches of 256. Construct the FAISSindexFlatIP vector index, add all normalized vectors to the index, and calculate semantic retrieval equivalent to cosine similarity using the inner product of the normalized vectors. The vector index is exported as a binary file (fault_index.faiss), and the metadata (including fault_id, date, line, professional, fault_type, location, zone_type, phenomenon, cause, solution, and repair_hours) is serialized as a binary file (fault_meta.pkl) for storage.

[0126] like Figures 3 to 7 As shown, the online policy generation phase includes:

[0127] Step S2, Intent Classification. The user inputs a natural language maintenance question via the web interface or API. The system first classifies the question's intent using a rule classifier. In an example run, the user inputs the maintenance question, "How to handle a malfunction in the Line 3 video surveillance system?"

[0128] The rule classifier executes the following matching logic: it iterates through the predefined set of line names (including "Line 1", "Line 2", "Line 3", "Line 4", "Line 10", "S1 Airport Line", "S3 Ninghe Line", "S6 Ningju Line", "S7 Ningli Line", "S8 Ningtian Line", "S9 Ninggao Line") one by one, finds a match for "Line 3", and extracts the line entity as "Line 3"; it sorts the keywords from longest to shortest and matches them one by one against the fault type keyword mapping table, finds a match for "video surveillance", and extracts the fault type entity as "video surveillance system fault"; it finds that the question contains the keyword "how to handle", matches factual signal words, and initially classifies it as a query intent for handling solutions with a confidence level of 0.90; because both the line entity and the fault type entity are identified, the confidence level is adjusted to 0.95.

[0129] Step S3, Rule Patch Correction. The rule patch module checks whether the initial intent classification result needs correction. In this example, the initial intent is a solution query, which matches the factual keywords and does not require correction.

[0130] If an operations and maintenance (O&M) user enters the question "Ranking of signal faults on each line," the rule classifier might classify the intent as an open O&M question due to a lack of sufficiently clear statistical signal terms. In this case, the rule patching module detects that the question contains the ranking keyword "ranking," corrects the intent type from open O&M question to statistical analysis, and sets the confidence level to 0.85. Simultaneously, since the question includes "each line" as a statistical dimension indicator, the statistical grouping dimension is set to "by line."

[0131] If an operations and maintenance (O&M) user enters the question "Which sites have both signal and communication failures?", the rule classifier might initially classify it as an open O&M Q&A. The rule patching module detects that the question matches the regular expression pattern "both X and Y" and identifies two or more failure type entities ("signal" and "communication"), thus correcting the intent type from open O&M Q&A to a multi-hop related query.

[0132] Step S4, dual-path hybrid retrieval. Query the weight mapping table based on the corrected intent type to obtain the retrieval parameters.

[0133] For the intent to query the treatment plan (Vw=0.35, Gw=0.65, Vk=3, Gk=5):

[0134] The vector retrieval channel encodes the operation and maintenance questions into normalized vectors using the same BGE-large-zh-v1.5 model, and retrieves the top-3 most similar records in the FAISS index.

[0135] The graph retrieval channel executes the following Cypher query: Matches fault event nodes (FaultEvent), connects them to the line node named "Line 3" via the OCCURRED_ON_LINE relationship, connects them to the fault type node named "Video Surveillance System Fault" via the IS_TYPE relationship, and optionally connects them to the location node via the AT_LOCATION relationship; the filtering condition is that the handling plan is not empty; sorts the records in descending order of the frequency of occurrence of the handling plan, and returns the fault number, line, fault type, location, fault phenomenon, fault cause, handling plan, repair time and frequency of the first 5 records.

[0136] For statistical analysis purposes (Vw=0.00, Gw=1.00, Vk=0, Gk=10):

[0137] Skip the vector retrieval channel and only perform the graph retrieval channel. When the statistical dimension is "by line", construct a grouped aggregation Cypher query: group by line name, count the number of fault events and average repair time for each line, collect a list of fault types included in that line and one example handling solution, and return the top 10 results sorted in descending order of the number of fault events. When the statistical dimension is "by fault type", construct a grouped aggregation Cypher query: group by fault type name, count the number of fault events and average repair time for each fault type, collect a list of lines involving that fault type and one example handling solution, and return the top 10 results sorted in descending order of the number of fault events.

[0138] For multi-hop related query intents (Vw=0.20, Gw=0.80, Vk=2, Gk=8):

[0139] The graph retrieval channel constructs a cross-fault type same-location query: First, it matches all fault events of the first type of fault and their occurrence locations. Then, it matches fault events of the second type of fault in the same location set. It aggregates and counts the number of both types of fault events at each location, excludes intermediate nodes whose location names are in pure number format, and returns the top 8 results in descending order of the total number of fault events. The vector retrieval channel simultaneously retrieves the top-2 semantically similar records as a supplement.

[0140] For the open operation and maintenance Q&A intent (Vw=0.65, Gw=0.35, Vk=5, Gk=3):

[0141] Vector retrieval and graph retrieval are performed in parallel with their respective weights. Graph retrieval constructs a general Cypher query with optional filtering conditions of line, specialty, and / or fault type, and returns the first 3 records in descending order of date.

[0142] Step S5, Merge and Sort. Select a fusion strategy based on the intent type.

[0143] For queries regarding treatment plans, a graph-first fusion strategy is adopted: Gk graph search results are placed at the beginning; Vk vector search results are traversed, and if the fault number of a vector search result does not appear in the fault number set of the graph search results, it is appended to the end of the results list; the merged results list is then uniformly normalized and scored.

[0144]

[0145] Where rawScore(i) is the raw score of entry i (the graph results are assigned decreasing scores in descending order of frequency, and the vector results are assigned decreasing scores in descending order of similarity), and minScore and maxScore are the minimum and maximum raw scores of all entries, respectively; when maxScore equals minScore, the normalized score of all entries is set to 1.0. The top-5 entries are taken as the fusion search results.

[0146] For statistical analysis purposes, a map-exclusive fusion strategy is adopted: the map retrieval results are directly normalized and scored before returning the top-10 results.

[0147] For multi-hop related query intents, a graph-first fusion strategy is adopted: first, the graph retrieval results are normalized and scored; then, the non-repeating entries in the vector retrieval results are normalized and scored and added; finally, the top-8 results are returned.

[0148] For open operation and maintenance Q&A intents, the weighted inverse ranking fusion algorithm (RRF) is used, and the fusion score is calculated as follows (taking k=60 as an example):

[0149] For example, suppose an entry ranks 1st in the graph search results (rank_graph=0) and also 1st in the vector search results (rank_vec=0), with Vw=0.65 and Gw=0.35: Score = 0.65 × 1 / (60+0+1) + 0.35 × 1 / (60+0+1) ≈ 0.0164. If an entry only ranks 3rd in the graph search results (rank_graph=2) and does not appear in the vector search results (rank_vec takes the maximum rank value, e.g., 5): Score = 0.65 × 1 / (60+5+1) + 0.35 × 1 / (60+2+1) ≈ 0.0154. After sorting by fusion score from highest to lowest, the top-5 entries are selected and normalized.

[0150] Step S6: Operation and maintenance policy generation. The system reads the system prompt template (system.txt) and the intent-specific prompt template file corresponding to the intent type from the external prompt template directory. The system prompt template defines the operation and maintenance assistant role, capability boundaries, and policy generation principles; each intent-specific prompt template defines the policy generation structure and output format for different intent types.

[0151] Constructing Context Text: Each record in the fusion search results is traversed, and fields such as line, fault type, location, fault phenomenon (truncated to the first 150 characters), fault cause (truncated to the first 150 characters), handling plan (truncated to the first 200 characters), and repair duration are concatenated into structured context text. The maximum number of context entries varies depending on the intent type: handling plan queries retrieve the first 5 entries, statistical analysis retrieves the first 10 entries, multi-hop association queries retrieve the first 8 entries, open maintenance Q&A retrieves the first 5 entries, and classification judgment retrieves the first 3 entries.

[0152] Replace the {question} placeholder in the intent-specific prompt template with the maintenance question, and replace the {context} placeholder with the constructed context text. Concatenate the system prompt template with the filled intent-specific prompt template to form a complete prompt message, and send it to the local large language model service (Qwen3-4B) via an HTTP POST request. The request parameters include a maximum number of tokens to generate (1024), a temperature of 0.3, and a Top-p sampling value of 0.9. Receive the maintenance strategy text returned by the large language model.

[0153] When the large language model call times out (more than 300 seconds) or returns an error, the system automatically reverts to the template strategy generation mode: selects the corresponding predefined strategy template according to the intent type, and organizes the fields such as fault type, line, location, fault cause, handling plan, and maintenance time in the search results into a structured operation and maintenance strategy text output according to the template format.

[0154] Zero-match inference mode: When the fusion search result is empty, the system constructs an inference guidance context, the content of which is: "Knowledge base search result is empty - no case directly matching this question was found. Please provide reasonable operation and maintenance strategy suggestions based on general operation and maintenance knowledge and industry practices of subway communication / signaling systems, combined with the equipment type described in the question. The strategy text must begin with a clear statement: "The following are inference suggestions based on general operation and maintenance knowledge, not direct cases from the knowledge base. Please judge based on the actual situation on site." The inference guidance context is used as a context text filling prompt template and sent to the local large language model to generate the inference strategy text.

[0155] Example 2

[0156] This embodiment provides a metro signaling operation and maintenance strategy generation system based on large model and vector-graph dual-path knowledge enhancement for implementing the method described in Embodiment 1, including:

[0157] The data preprocessing and knowledge base construction module is used to acquire subway signal fault registration data, perform data cleaning and structuring, construct a fault knowledge graph, and establish a vector semantic index. This module includes a data transformation submodule, a data cleaning submodule, a knowledge graph import submodule, and a vector index construction submodule.

[0158] The intent classification module acquires natural language operation and maintenance questions input by the user, classifies the intent using a rule classifier, and corrects the initial intent type using a rule patching module to obtain the corrected intent type and signal device entity recognition results. This module includes a rule classifier submodule, an entity recognition submodule, and a rule patching correction submodule. Furthermore, this module can optionally integrate a vector KNN classifier submodule to complement the rule classifier.

[0159] The dual-path hybrid retrieval module adaptively allocates retrieval weights and retrieval quantities to the vector retrieval channel and the graph retrieval channel based on the corrected intent type, performing a dual-path hybrid retrieval. This module includes a weight mapping submodule, a vector retrieval submodule, and a graph retrieval submodule.

[0160] The fusion and ranking module is used to fuse and rank the vector retrieval results and the graph retrieval results according to the intent type by selecting the corresponding fusion strategy. This module includes a fusion strategy selection submodule, a normalization scoring submodule, and a ranking output submodule.

[0161] The strategy generation module loads corresponding prompt templates based on intent type, uses fused search results as context to construct prompt information, inputs local large language model to generate subway signal operation and maintenance strategy text, and automatically switches to inference mode when search results are empty. This module includes a prompt template management submodule, a context construction submodule, a large language model invocation submodule, a template strategy rollback submodule, and an inference mode submodule.

[0162] The specific implementation methods of the above modules are the same as those in Example 1, and will not be repeated in this example.

[0163] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for generating subway signaling operation and maintenance strategies based on large model and vector-graph dual-path knowledge enhancement, characterized in that, Includes the following steps: S1, acquire subway signal fault registration data, perform data cleaning and structuring processing on the fault registration data, construct a fault knowledge graph and establish a vector semantic index; S2, obtain the user's input natural language operation and maintenance question, classify the question by intent through a rule classifier, and obtain preliminary intent type and signal device entity recognition results; S3, The preliminary intent type is corrected by the rule patching module to obtain the corrected intent type; S4. Based on the corrected intent type, adaptively allocate the retrieval weights and retrieval quantity of the vector retrieval channel and the graph retrieval channel, perform dual-path hybrid retrieval, and obtain vector retrieval results and graph retrieval results; S5. Based on the intent type, select the corresponding fusion strategy to fuse and sort the vector retrieval results and the graph retrieval results to obtain the fused retrieval results; S6. Load the corresponding prompt template according to the intent type, use the fusion retrieval result as context to construct prompt information according to the prompt template, input it into the local large language model, and generate subway signal operation and maintenance strategy text.

2. The method according to claim 1, characterized in that, In step S1, constructing the fault knowledge graph includes: extracting entities such as line, region type, location, and fault type from the fault registration data as knowledge graph nodes, and establishing associations with the fault event as the central node and the line, fault type, and location; the knowledge graph is stored in a graph database, and the graph database is the Neo4j graph database.

3. The method according to claim 1, characterized in that, In step S1, establishing a vector semantic index includes: concatenating each fault record into a retrieval text according to a preset text template, wherein the retrieval text includes fields such as route, specialty, fault type, location, fault phenomenon, fault cause, and handling process; encoding the retrieval text into a normalized vector using a pre-trained language model, and constructing a vector index based on inner product search, wherein the vector index is a FAISS index.

4. The method according to claim 1, characterized in that, In step S2, the preliminary intent types include five types: handling solution query, statistical analysis, multi-hop association query, open operation and maintenance Q&A, and classification judgment; the rule classifier classifies intents based on the keyword signals contained in the question, and the keyword signals include factual signal words, statistical signal words, multi-hop association signal words, and classification judgment signal words.

5. The method according to claim 1, characterized in that, In step S3, the correction operation of the rule patching module includes: When the question contains factual keywords but the initial intent type is not a solution query, the intent type will be changed to a solution query. When the question contains statistical keywords but the initial intent type is neither a solution query nor a statistical analysis, the intent type will be corrected to statistical analysis. When the question contains cross-category keywords or meets the preset cross-sentence regular expression pattern, and more than two fault type entities are identified, the intent type will be modified to a multi-hop related query. When the specific intent type cannot be identified but the line entity and fault type entity have been identified, the intent type will be corrected to a solution query.

6. The method according to claim 1, characterized in that, In step S4, the intent adaptive weight allocation is performed according to a preset weight mapping table, which defines the vector retrieval weight, graph retrieval weight, vector retrieval quantity, and graph retrieval quantity for each intent type; wherein: The weight of graph retrieval for querying disposal solutions is greater than that of vector retrieval. Vector retrieval with statistical analysis intent has zero weight, and graph retrieval is used entirely. Graph retrieval has a greater weight than vector retrieval for multi-hop related query intents. The vector retrieval weight for open operation and maintenance Q&A intent is greater than the graph retrieval weight.

7. The method according to claim 1, characterized in that, In step S4, the graph retrieval constructs different structured query statements based on the intent type, including: For the intent to query handling solutions, construct a graph query that uses fault type and / or line as filtering conditions and sorts the handling solutions in descending order of frequency of occurrence; For statistical analysis purposes, a graph query is constructed with statistical dimensions as grouping conditions and the number of fault events as aggregation indicators. The statistical dimensions include grouping by line and grouping by fault type. For multi-hop related query intents, construct cross-fault type same location query to find common locations where two or more different fault types occur simultaneously; For the purpose of open operation and maintenance Q&A, construct a general graph query with fault type, line and / or profession as filtering conditions.

8. The method according to claim 1, characterized in that, In step S5, the fusion strategy is selected based on the differences in intent type: For queries regarding treatment plans, a graph-first fusion strategy is adopted, placing graph retrieval results at the top and adding non-repeating entries from vector retrieval results to the bottom, and then uniformly normalizing the scores. For statistical analysis purposes, a graph-exclusive fusion strategy is adopted, using only the graph retrieval results and not fusing the vector retrieval results; For multi-hop related query intents, a graph-first fusion strategy is adopted, which merges the non-repeating entries in the graph retrieval results and vector retrieval results and then performs unified normalized scoring. For open operation and maintenance Q&A intents, a weighted reciprocal sorting fusion algorithm is used, and the calculation formula is as follows: ； in, For vector retrieval weights, The weights for map retrieval are k, which is a preset constant. and These represent the ranking of the entry in the vector search results and the graph search results, respectively.

9. The method according to claim 1, characterized in that, Step S6 also includes a zero-match inference mode: when the fusion search result is empty, an inference guidance context is automatically constructed. The inference guidance context includes device type information and prompt information, which guides the large language model to generate inference strategy suggestions based on general signal operation and maintenance knowledge, and marks the inference identifier in the generated text to distinguish between the standard strategy generated based on the search case and the reference strategy generated based on inference. In step S6, each intent type corresponds to an independent prompt template file. The prompt template file is placed externally in the system running directory in the form of a text file. It is read from the text file in real time each time a prompt message is built, so as to support hot updates of prompt templates without restarting the system. When the prompt template file is missing, the built-in default prompt template is automatically used as a fallback.

10. A subway signaling operation and maintenance strategy generation system based on large model and vector-graph dual-path knowledge enhancement for implementing the method of any one of claims 1-9, characterized in that, include: The data preprocessing and knowledge base construction module is used to acquire subway signal fault registration data, perform data cleaning and structuring, construct a fault knowledge graph, and establish a vector semantic index. The intent classification module is used to acquire natural language operation and maintenance questions input by users, classify the intents through a rule classifier, and correct the initial intent types through a rule patching module to obtain the corrected intent types and signal device entity recognition results. The dual-path hybrid retrieval module is used to adaptively allocate the retrieval weights and retrieval quantities of the vector retrieval channel and the graph retrieval channel according to the corrected intent type, and to perform dual-path hybrid retrieval. The fusion and ranking module is used to select the corresponding fusion strategy based on the intent type to fuse and rank the vector retrieval results and the graph retrieval results. The strategy generation module is used to load the corresponding prompt template according to the intent type, use the fused search results as context to construct prompt information, input the local large language model to generate subway signal operation and maintenance strategy text, and automatically switch to inference mode when the search results are empty.

Images