Public traffic demand response method and equipment based on fault event, and medium

Abstract

The embodiment of the invention discloses a public traffic demand response method and device based on a fault event and a medium, and relates to the technical field of large models, and the method comprises the steps: obtaining fault traffic event text information and fault site position information corresponding to the fault event through a public traffic operation interface, acquiring corresponding real-time emergency structured data based on the fault station position information, wherein the real-time emergency structured data comprises public transport card swiping records and rented vehicle track data; determining an event space-time coding vector corresponding to the fault event according to the fault traffic event text information and the real-time emergency structured data, and constructing a fault event cache layer between the large model and a preset MongoDB database based on the event space-time coding vector by taking the fault event identifier as a namespace; and under the triggering of a decision request of the large model, carrying out vector query in the fault event cache layer to determine a demand hit vector, responding to the public transport demand through the large model, and determining response decision information.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of large model, and particularly relates to a public transportation demand response method based on fault events, equipment and medium. BACKGROUND

[0002] In the field of public transportation, accurately grasping travel demand is crucial for optimizing route planning, deploying vehicle resources, and improving service quality. With the expansion of urban size and the increase of population flow, public transportation travel data is growing explosively, and traditional data processing and analysis methods are difficult to cope with such massive and complex data. Large models have shown strong capabilities in natural language processing, data analysis, and other fields, and can perform in-depth analysis on large-scale public transportation data to mine potential patterns and travel demand patterns. Current intelligent transportation systems generally use a technical route combining large model data analysis and non-relational database storage when responding to public transportation fault events. The mainstream solution relies on databases such as MongoDB to store real-time traffic data (such as bus card records, taxi trajectory), and uses large models to analyze travel demand and generate decisions.

[0003] In the process of using large models to process massive traffic data, there is a problem of long data access path, which leads to delayed decision response. Large models directly access databases (such as MongoDB) to obtain raw data, perform demand prediction and resource scheduling, and in this process, large models need to repeatedly read data from disk databases, and I / O bottlenecks are significant. Especially when a fault event such as a traffic fault occurs, the direct access to the database for data acquisition further increases the decision-making time for the fault event. Therefore, when responding to public transportation demand in a sudden fault event, the traditional direct access method of the database has the problem of low data access efficiency, leading to delayed decision response. SUMMARY

[0004] One or more embodiments of the present specification provide a public transportation demand response method based on fault events, equipment and medium, to solve the technical problem that when responding to public transportation demand in a sudden fault event, the traditional direct access method of the database has the problem of low data access efficiency, leading to delayed decision response.

[0005] One or more embodiments of the present specification adopt the following technical solutions:

[0006] One or more embodiments of the specification provide a public transportation demand response method based on a failure event, the method comprising: obtaining failure traffic event text information and failure site location information corresponding to a failure event through a public transportation operation interface, to collect real-time emergency structured data corresponding to other public transportation based on the failure site location information, wherein the real-time emergency structured data comprises public transportation card swiping records and taxi trajectory data; determining an event space-time coding vector corresponding to the failure event according to the failure traffic event text information and the real-time emergency structured data, and constructing a failure event cache layer between a large model and a preset MongoDB database based on the event space-time coding vector, with a failure event identifier as a namespace; under a decision request trigger of the large model, performing vector query in the failure event cache layer to determine a demand hit vector, to respond to public transportation demand through the large model and determine response decision information.

[0007] One or more embodiments of the specification provide a public transportation demand response device based on a failure event, comprising:

[0008] at least one processor; and

[0009] a memory in communication connection with the at least one processor; wherein

[0010] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above method.

[0011] One or more embodiments of the specification provide a non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions are configured to execute the above method.

[0012] The at least one technical scheme adopted by the embodiments of the present specification can achieve the following beneficial effects: Through the technical scheme of the embodiments of the present specification, an efficient data channel is established between the database and the large model by constructing a fault event cache layer. The cache layer takes the event space-time coding vector as a carrier, converts the original data into a preprocessed vector form, eliminates the complex query analysis overhead, and realizes event-specific data isolation through the fault event identifier namespace mechanism to avoid redundant data interference. When the large model request hits the cache layer, the vectorized data is directly returned, skipping the database disk reading process, significantly shortening the data supply path, and fundamentally breaking through the I / O bottleneck limit. In the traditional scheme, the database needs to be queried in real time when a fault event occurs, which aggravates the delay in a high-concurrency scenario. The embodiments of the present specification realize preloading of the event space-time coding vector through the preloaded vector cache layer, and the cache layer has stored the structured vector when a fault occurs, so the large model does not need to wait for real-time data conversion. The cache layer is based on memory operation to replace database query, shortening the key decision window. The fault event identifier is used as a key value to ensure zero retrieval delay of target data, significantly accelerating the end-to-end process from fault diagnosis to decision generation, especially avoiding response blocking in a high-concurrency traffic fault scenario. In addition, the cache layer undertakes high-frequency reading requests of the large model, reduces the concurrent pressure of the database, vectorized data reduces the preprocessing calculation amount of the large model, releases resources for core decision-making, the cache layer stores data in isolation according to events, avoids invalid data occupying memory space, improves overall resource utilization efficiency, and enhances system stability and scalability. The event space-time coding vector uniformly represents the characteristics of multi-source data, eliminating the ambiguity of the original data. Based on the decision type, the optimal data subset is matched to exclude low-value information interference, so that the decision result is more in line with the actual needs of the fault scenario, and misjudgment caused by inconsistent data or information redundancy is avoided. BRIEF DESCRIPTION OF DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present specification or the prior art, brief introductions to the drawings needed in the embodiments or prior art descriptions will be given below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained by those skilled in the art without creative labor. In the drawings:

[0014] Figure 1 A flowchart of a public transportation demand response method based on a fault event provided by the embodiments of the present specification;

[0015] Figure 2 A structural schematic diagram of a public transportation demand response device based on a fault event provided by the embodiments of the present specification. DETAILED DESCRIPTION

[0016] In order for those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described in the specification below in conjunction with the drawings in the specification. Obviously, the described embodiments are only part of the embodiments of the specification, not all. Based on the embodiments of the specification, all other embodiments obtained by those of ordinary skill in the art without creative labor should be within the scope of protection of the specification.

[0017] The embodiment of the specification provides a public transport demand response method based on a fault event. It should be noted that the execution subject in the embodiment of the specification can be a server or any device with data processing capability. Figure 1 The flowchart of the public transport demand response method based on the fault event provided by the embodiment of the specification is shown in Figure 1 As shown, the method mainly includes the following steps:

[0018] In step S101, the fault traffic event text information and the fault station position information corresponding to the fault event are obtained through a public transport operation interface, so as to collect real-time emergency structured data corresponding to other public transport based on the fault station position information.

[0019] The real-time emergency structured data includes public transport card swiping records and taxi trajectory data.

[0020] In an embodiment of the specification, multi-source data in the field of public transport is collected, including but not limited to bus card swiping records, subway station entry and exit data, taxi trip data, real-time traffic information, etc. The data is preprocessed to remove noise and outliers. Natural language processing technology and data feature extraction algorithm are used to convert various travel data into vector form. For example, the passenger boarding and alighting time, station information, etc. in the bus card swiping record are converted into time-space feature vectors; the time, starting point, ending point, travel distance, etc. in the taxi trip data are converted into time-position-distance feature vectors. For text type traffic information such as traffic announcements and passenger feedback, semantic understanding and vectorization processing are performed by a large model to obtain semantic feature vectors.

[0021] In the emergency response of public transportation failure, real-time and accurate data collection needs to be ensured. Failure events have three characteristics: suddenness (such as subway signal failure), diffusion (such as single station failure causing congestion in the surrounding road network), and timeliness (the short golden window of relief). If only relying on static historical data or single traffic mode information, it will lead to misjudgment of the failure influence range and incomplete decision information. For example, when the subway is out of service, the traditional method only collects data at the failure site, ignores the dynamic of surrounding public transportation / taxi capacity, and cannot quantify the size of passenger retention; and the analysis of text type failure announcements (such as contact net failure) and structured data (such as public transportation card swiping tidal regularity) is fragmented, making it difficult to build a complete travel demand portrait.

[0022] In an embodiment of the present specification, the API interface provided by the subway operation system is used to subscribe to the failure event stream in real time, the text information of the failure traffic event such as the failure type description and the influence level is extracted by analyzing the JSON format message, and the location information of the failure site is extracted. Subsequently, based on the GPS coordinates of the location information of the failure site of the failure site, the data collection radius is dynamically set through the geofencing technology. For example, taking the failure point as the center, the public transportation data collection range is set to the first preset kilometer, which can be set to 1 kilometer or other reasonable distance covering the walking connection, and the taxi data collection range is extended to the second preset kilometer, for example, 2 kilometers, taking into account the short-distance transfer demand. Then, the real-time card swiping record stream is accessed through the SDK of the public transportation intelligent scheduling system, the passenger boarding and alighting time stamps and site coordinates within the collection circle during the failure occurrence time to the current time are filtered, and the same space-time range is obtained through the TCP long connection of the taxi supervision platform. The trajectory point sequence includes vehicle ID, start / endpoint coordinates, and passenger carrying state; finally, the original data is preprocessed in a streaming manner, the GPS drift points (such as abnormal trajectories with a speed of >120km / h) are removed, the missing site codes are filled (based on the reverse geocoding of the road network topology library), and the data is stored in the Kafka message queue according to the failure event ID for subsequent processes.

[0023] Through the above technical solution, compared with the conventional fixed radius collection, the present embodiment dynamically determines the collection range according to the characteristics of the transportation tool, the public transportation data focuses on the short-distance connection demand circle, and the taxi data covers the medium-distance transfer circle, avoiding data overload or missing. At the same time, through the space-time range filtering (only keeping the valid data stream after the failure occurs), irrelevant historical noise is removed, and the input data is closely related to the current failure scene.

[0024] In step S102, according to the fault traffic event text information and the real-time emergency structured data, an event space-time coding vector corresponding to the fault event is determined, and a fault event cache layer is constructed between a large model and a preset MongoDB database based on the event space-time coding vector, with a fault event identifier as a namespace.

[0025] According to the fault traffic event text information and the real-time emergency structured data, an event space-time coding vector corresponding to the fault event is determined, and a fault event cache layer is constructed between a large model and a preset MongoDB database based on the event space-time coding vector, with a fault event identifier as a namespace.

[0026] In an embodiment of the present specification, a text type fault announcement such as “signal system paralysis” describes the nature of the event, bus card records reflect the space-time distribution of passenger flow, and taxi trajectory reflects the dynamic of transport supply. If these heterogeneous data are processed independently, it will lead to the fragmentation of decision-making basis, for example, only text information cannot quantify the degree of passenger flow backlog, and only trajectory data cannot associate the root cause of the fault.

[0027] The pre-trained BERT model is used to analyze the fault traffic event text information, extract key entities such as fault type and impact range, and generate a semantic feature sub-vector. Specifically, the context semantics are captured through a word embedding layer, and a fixed dimension vector representation is output. At the same time, the bus card record flow is analyzed according to the passenger boarding and alighting timestamps and station GPS coordinates to construct a space-time displacement chain, and the passenger flow rate between stations within a unit time is calculated using a sliding window to generate a space-time displacement sub-vector. The taxi trajectory data is processed synchronously, the straight-line displacement vector from the starting point to the ending point is calculated based on the trajectory point sequence, and the travel time is labeled combined with the timestamp to generate a space-time trajectory feature sub-vector. Finally, the three types of sub-vectors are aggregated through a dynamic weighting fusion module. The meteorological bureau API data is accessed in real time, if it is raining, the weight of the semantic feature sub-vector is increased, if it is in the morning and evening peak, the weight of the space-time displacement sub-vector is strengthened, and the passenger flow dynamics dominates, the weighted result is normalized and output as an event space-time coding vector of a unified dimension, and the fault event ID identifier is injected and stored in the vector database. The specific weight setting method can be based on actual demand for weight assignment.

[0028] Compared with the discrete mode of independently processing text, swiping cards, and track data in the conventional scheme, the deep coupling of multi-modal data is achieved through the sub-vector fusion mechanism in the technical solution. For example, when a "catenary failure" occurs in the subway, the semantic sub-vector captures the "power interruption" property, the spatiotemporal displacement sub-vector quantifies the 300% mutation of passenger flow growth within 15 minutes of the fault station, and the spatiotemporal track sub-vector shows the trend of taxis gathering around the fault point. The projection of three-dimensional features in a unified vector space enables the large model to accurately deconstruct the fault influence chain and avoid misjudgments caused by feature fragmentation in traditional methods, such as misdiagnosing a temporary passenger flow peak as a normal commuting tide. The dynamic weighting strategy enables the vector generation process to have scene awareness, automatically increases the weight of semantic features in heavy rain scenarios, and ensures that the "heavy rain outage" announcement dominates the vector expression. The weight of spatiotemporal displacement features is enhanced during the morning peak period, making passenger flow density data the core of decision-making. This dynamic nature solves the problem of fixed weight addition in complex failures in conventional static weighting. The traditional scheme requires inputting text classification results, card swipe statistics reports, and track clustering charts into the large model separately, forcing the model to consume additional resources to align multi-source features. The instant fusion vector provided by the present specification enables the large model to complete analysis through a single forward propagation.

[0029] A fault event cache layer is constructed between the large model and the pre-set MongoDB database, specifically including: listening to log change events of the MongoDB database, and when a fault event is detected, creating an independent cache space with a fault event identifier; according to the fault event identifier, preloading the corresponding event spatiotemporal encoding vector into the independent cache space to construct the fault event cache layer.

[0030] In the process of public transportation fault emergency response, in the traditional way, the large model directly reads and writes the MongoDB database, which has problems of data access delay and resource competition conflict. Disk I / O operation makes it difficult to achieve millisecond-level response, especially in the early morning peak multi-station chain failure scenario, database query queue accumulation leads to decision instruction lag; and, the general cache cannot isolate different fault event data, and high-priority event vectors are squeezed out of the cache by low-value historical data, causing the loss of key analysis basis; in addition, when analyzing a new fault event for the first time, the historical database needs to be searched in full, missing the golden time window for passenger flow dissipation.

[0031] In an embodiment of the present specification, the MongoDB Change Stream API is enabled to listen to the change event stream of the fault_event collection, and a filter is configured to capture the fault event insertion operation (operationType: "insert"); when a new event is detected (such as the log contains event_id:

[0032] The cache controller is triggered immediately (F20240721_0830 and severity_level field); the controller generates a unique namespace identifier according to the event ID, and the naming rule is as follows: fault_cache:{event_id}, and an independent memory pool is allocated in the cache layer, and the minimum retention period parameter is set synchronously; then the preloading engine is called, similar fault vectors in the MongoDB history library are retrieved through a circular geographical index, matching rules are matched, the same line, adjacent stations, and similar fault types are matched, and the associated event space-time coding vectors are loaded into the newly created namespace in batches; finally, a bidirectional synchronization channel is established, and the event-related fields in the oplog are continuously monitored, such as updating affected_stations when the impact range expands, refreshing the cache data in real time, and writing the cache layer modification back to MongoDB to ensure consistency. The entire process is ensured to be atomic through distributed transaction locks to avoid multi-event concurrency conflicts.

[0033] After the construction of the fault event cache layer, the method further includes: monitoring the number of caches in the fault event cache layer in real time; when the number of caches meets a preset cache capacity threshold, determining a fault event level corresponding to the fault event cache layer; based on the fault event level, determining a minimum retention period threshold corresponding to a cache vector in the fault event cache layer, to manage the cache vector based on the minimum retention period threshold.

[0034] Fault events have obvious hierarchical differences, such as the number order difference between the handling priority of local device failure and natural disaster type full line stoppage. The traditional cache scheme adopts a static eviction strategy, which will have problems such as key data being evicted, and high-level event vectors (such as passenger flow surge data caused by heavy rain) may be squeezed out by low-value data due to cache space competition, causing the disruption of the solution chain. In addition, when there are many faults during the morning peak, low-impact events occupy memory for a long time, hindering the loading of high-priority data, causing emergency resource mismatch; the cache release method with fixed retention period cannot adapt to the dynamic needs of fault evolution.

[0035] In an embodiment of the present specification, a lightweight monitoring agent cluster is deployed in the fault event cache layer to collect the number of vectors and memory water level indicators of each independent namespace in real time. When the number of cache entities in a specific namespace reaches the preset capacity warning line, such as the memory occupancy rate reaching the critical threshold, an event level analysis is triggered immediately. By calling the real-time state interface of the subway operation system, the level label of the current namespace bound event is obtained, such as natural disaster identification as the highest level; then the level-retention period mapping rule table preset in the MongoDB configuration library is accessed, the storage structure is a key-value pair of event level code and time threshold, and the minimum retention period benchmark value corresponding to the event level is matched. Next, the eviction logic of the namespace is reconstructed, covering the standard LRU (Least Recently Used) algorithm, and the associated vector is forced to lock within the retention period threshold to prohibit eviction, while sending an elastic expansion instruction to the resource coordinator, such as automatically mounting a standby cache node; finally, the strategy state of each node is synchronized through a distributed consistency protocol (such as Raft algorithm) to ensure that the cache management behavior across the cluster is executed atomically.

[0036] Through the above technical solution, compared with the traditional homogeneous cache solution, the dynamic coupling of event level and retention period allows high-value data to be retained, achieving high-level event data availability and avoiding decision-making failure risks caused by cache eviction. Based on the event level elastic resource scheduling, the optimal allocation of limited cache space is realized, significantly reducing redundant memory reservation, effectively improving cache resource utilization and reducing resource allocation delay in early peak concurrent failure scenarios.

[0037] Step S103, under the triggering of the decision request of the large model, vector query is performed in the fault event cache layer to determine the demand hit vector, so as to respond to public transportation demand through the large model and determine the response decision information.

[0038] Under the triggering of the decision request of the large model, vector query is performed in the fault event cache layer to determine the demand hit vector, specifically including: according to the fault event, matching is performed in the fault event cache layer to determine at least one independent cache space in the fault event cache layer; obtaining the decision request information of the large model, wherein the decision request information includes a decision type, and the decision type includes a single-point connection scheduling type and a line cooperative optimization type; based on the decision type, vector query is performed in the at least one independent cache space to determine the demand hit vector.

[0039] According to the fault event, matching is performed in the fault event cache layer to determine at least one independent cache space in the fault event cache layer, specifically including: according to the fault event identifier of the fault event, performing identifier matching in the fault event cache layer, when there is a matching independent cache space corresponding to the fault event identifier, determining the independent cache space corresponding to the fault event with the matching independent cache space; based on the fault event identifier and the space identifier of each independent cache space in the fault event cache layer, similarity calculation is performed to determine at least one independent cache space whose similarity satisfies a preset threshold.

[0040] The fault event has dynamic evolution characteristics, such as single-station fault diffusion to multi-station paralysis, and historical similarity, such as rainstorm event and historical flood failure mode convergence. If a static precise matching method that only relies on event ID complete matching is used, there are problems of new fault response delay and associated data fragmentation. The first occurrence of fault type (such as new device fault) has no historical cache space, and needs to search MongoDB in full, missing the golden time window for resolving; and the cache data of similar fault events (such as adjacent subway stations with the same type of signal fault) cannot be reused, resulting in lack of continuity of the analysis model.

[0041] In an embodiment of the present specification, when the fault event is determined, first, precise identifier matching is performed in the cache layer global hash table. The independent cache space is retrieved with event ID as the key. If there is a complete matching namespace, such as preloading completed before the fault occurs, the space is immediately locked as the target container; and the space identifier of the fault event, i.e. the GeoHash encoding of the fault station GPS coordinates, such as wx4er5t, is extracted, the space identifier field of all independent spaces in the cache layer is traversed, and the metadata is stored in the cache vector. The similarity score of the current fault station and the historical station coordinates is calculated by the edit distance algorithm, wherein the score interval is standardized to [0, 1], and the candidate spaces with a score greater than a preset similarity threshold are screened; the candidate spaces and the matching independent cache space of complete matching are determined as the independent cache space.

[0042] If the matching is unsuccessful, the vector data is retrieved from MongoDB. It should be noted that the vectorized travel demand data is stored in MongoDB. Using the document data model of MongoDB, each vector data and its related metadata are organized into a document for storage. For example, a bus travel demand vector document may contain vector values, corresponding bus routes, timestamps, passenger numbers, and other information. Indexes are established in MongoDB for commonly queried fields of vector data, such as vector identifiers, time ranges, geographic locations, etc. Through index optimization, the speed of retrieving vector data from MongoDB is accelerated. When the cache is not hit, the required data can be quickly read from MongoDB and stored in the cache for subsequent use. When the vector data in MongoDB is updated (such as new data, data correction, etc.), it is synchronized to the cache in a timely manner to ensure the real-time and accuracy of the cache data. At the same time, after modifying the data in the cache, it can also be updated to MongoDB in a timely manner to ensure data consistency.

[0043] Based on the decision type, vector query is performed in the at least one independent cache space to determine a demand hit vector, specifically including: based on the decision type, matching a corresponding spatio-temporal value calculation operator to perform spatio-temporal value calculation on each event spatio-temporal encoding vector through the spatio-temporal value calculation operator to determine a vector spatio-temporal value; and performing vector query in the at least one independent cache space according to the vector spatio-temporal value and a preset spatio-temporal value threshold to determine a demand hit vector. Based on the decision type, the corresponding spatio-temporal value calculation operator is matched, specifically including: when the decision type is the single-point connection scheduling type, the spatio-temporal value calculation operator includes a vector time efficiency parameter and a spatial tightness parameter; and when the decision type is the line coordination optimization type, the spatio-temporal value calculation operator includes a road network coverage rate parameter and a vector time efficiency parameter.

[0044] In an embodiment of the present specification, when the large model generates a decision request, the structured decision label is carried in the request message, and the decision type identifier is identified to determine the decision type. According to the decision type, the spatio-temporal value coefficient calculation formula is selected.

[0045] If it is a single-point connection scheduling class (such as subway station equipment failure), the time validity parameter of the vector is obtained, the time validity duration of each vector is obtained by subtracting the vector update timestamp corresponding to each vector from the current time, and the reciprocal of the invalidity duration is determined as the vector invalidity parameter. And calculate the spatial density parameter, calculate the proportion of the number of buses / taxis within 1 kilometer of each vector corresponding fault point in the total transport capacity of the region. Weighted sum of vector time validity parameter and spatial density parameter, get the space-time value coefficient of each vector. If it is a line cooperative optimization class (such as bus-metro connection interruption), the road network coverage rate parameter is obtained, the interval stations between the vector station position and the fault station are calculated based on the station position corresponding to each vector, the reciprocal of the number of interval stations is determined as the road network coverage rate parameter, and the vector time validity parameter of each vector is calculated; the road network coverage parameter and the vector time validity parameter are weighted and summed to obtain the space-time value coefficient of each vector. It should be noted that the weight parameter in the embodiments of the present specification can be valued according to experience and actual application scenarios, or can be realized by other weight setting methods. Subsequently, the event space-time coding vector in the target independent cache space is traversed, the value of each vector is calculated, and the standardized space-time value coefficient is output. Finally, the vectors whose coefficients exceed the dynamic threshold are selected as demand hit vectors, and the dynamic threshold here can be automatically adjusted according to the event level. After obtaining the demand hit vector, the public transportation demand is inferred based on the large model to generate target decision information. Through the differentiated calculation model driven by the decision type, the accuracy of public transportation emergency response is effectively improved.

[0046] Through the technical solutions of the embodiments of the present specification, an efficient data channel is established between the database and the large model by constructing a fault event cache layer, the cache layer takes the event space-time coding vector as a carrier, and the original data is converted into a preprocessed vector form, the complex query analysis overhead is eliminated, the fault event identification namespace mechanism realizes event exclusive data isolation, and the interference of redundant data is avoided, when the large model request is hit in the cache layer, the vectorized data is directly returned, the database disk reading process is skipped, the data supply path is significantly shortened, and the I / O bottleneck limitation is fundamentally broken; in a traditional scheme, the database needs to be queried in real time when a fault event occurs, and the delay is aggravated in a high concurrency scenario. The embodiments of the present specification realize preloading of the event space-time coding vector through the prepositioned vectorized cache layer, the cache layer has stored the structured vector when the fault occurs, and the large model does not need to wait for real-time data conversion; the cache layer is based on memory operation to replace database query, and the key decision window is shortened; the fault event identification is used as a key value, the target data zero retrieval delay is ensured, the end-to-end process from fault diagnosis to decision generation is greatly accelerated, especially in a high concurrency traffic fault scenario, response blocking is avoided, in addition, the cache layer undertakes the high-frequency reading request of the large model, the database concurrency pressure is reduced, the vectorized data reduces the preprocessing calculation amount of the large model, resources are released for core decision, the cache layer stores according to the event isolation, invalid data occupation of the memory space is avoided, the overall resource utilization efficiency is improved, and the system stability and scalability are enhanced; the event space-time coding vector is used to uniformly represent the multi-source data features, and the original data ambiguity is eliminated; based on the decision type, the optimal data subset is matched, the interference of low-value information is excluded, the decision result is more in line with the actual needs of the fault scenario, and misjudgment caused by inconsistent data or information redundancy is avoided.

[0047] The embodiments of the present specification also provide a public transportation demand response device based on a fault event, as shown in Figure 2 The device includes at least one processor, and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above method.

[0048] The embodiments of the present specification also provide a non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions are configured to execute the above method.

[0049] Each of the embodiments in the present specification is described in a progressive manner, and the same or similar parts of each of the embodiments can be referred to each other. Each of the embodiments focuses on the difference from other embodiments. In particular, for the device, equipment, and non-volatile computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts are referred to the part of the method embodiment.

[0050] The above described embodiments of the present specification. Other embodiments are within the scope of the following claims. In some cases, the acts or steps recited in the claims can be performed in a different order than those in the embodiments and still achieve desirable results. Additionally, the processes depicted in the accompanying figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous or necessary.

[0051] The device and medium provided by the embodiments of the present specification are one-to-one corresponding with the method, therefore, the device and medium also have similar beneficial technical effects as the method corresponding thereto, since the beneficial technical effects of the method have been described in detail above, therefore, the beneficial technical effects of the device and medium will not be described here again.

[0052] Those skilled in the art will understand that the embodiments of the present specification can be provided as a method, system, or computer program product. Therefore, the present specification can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0053] The present specification is described with reference to flowcharts and / or block diagrams of the method, device (system), and computer program product according to the embodiments of the present specification. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The function specified in one or more flows and / or blocks Figure 1 The function specified in one or more flows and / or blocks

[0054] These computer program instructions can also be stored in a computer-readable memory that can direct the computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction devices that implement the functions specified in the flowcharts and / or block diagrams. Figure 1 The function specified in one or more flows and / or blocks Figure 1 The function specified in one or more flows and / or blocks

[0055] These computer program instructions can also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart or multiple flows and / or blocks Figure 1 of the flow or multiple flows and / or blocks Figure 1 of the flow or multiple flows and / or blocks

[0056] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0057] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) about which the computer stores the information. The memory is an example of computer readable media.

[0058] Computer readable media includes permanent and non-permanent, moveable and non- moveable media that can be implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0059] It is also important to note that the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element. … ” An element proceeded by "comprises... a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0060] The above merely provides one or more embodiments of the present specification and is not intended to limit the present specification. One of ordinary skill in the art can make various modifications and changes to one or more embodiments of the present specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of the present specification should be included in the scope of claims of the present specification.

Claims

1. A public transportation demand response method based on a failure event, characterized by, The method comprises: Obtaining fault traffic event text information and fault site location information corresponding to the fault event through a public transportation operation interface, to collect real-time emergency structured data corresponding to other public transportation based on the fault site location information, wherein the real-time emergency structured data comprises public transportation card swiping records and taxi trajectory data; According to the fault traffic event text information and the real-time emergency structured data, determining an event space-time coding vector corresponding to the fault event, and based on the event space-time coding vector, constructing a fault event cache layer between a large model and a preset MongoDB database, with a fault event identifier as a namespace; Upon triggering of a decision request of the large model, performing vector query in the fault event cache layer to determine a demand hit vector, to respond to public transportation demand through the large model and determine response decision information.

2. A public transportation demand response method based on a failure event according to claim 1, characterized in that, According to the fault traffic event text information and the real-time emergency structured data, determining an event space-time coding vector corresponding to the fault event, specifically comprising: Analyzing the fault traffic event text information to generate a semantic feature sub-vector, analyzing time stamps and site coordinates in the public transportation card swiping records to generate a space-time displacement sub-vector, and fusing start / endpoint coordinates and time stamps in the taxi trajectory data to generate a space-time trajectory feature sub-vector; Weighted aggregation is performed on the semantic feature sub-vector, the space-time displacement sub-vector and the space-time trajectory feature sub-vector to generate the event space-time coding vector corresponding to the fault event.

3. The public transportation demand response method based on a failure event according to claim 1, characterized by, Constructing a fault event cache layer between a large model and a preset MongoDB database, specifically comprising: Monitoring log change events of the MongoDB database, and when a fault event is monitored, creating an independent cache space with a fault event identifier; According to the fault event identifier, preloading the corresponding event space-time coding vector to the independent cache space to construct the fault event cache layer.

4. A public transportation demand response method based on a fault event according to claim 3, characterized in that, After constructing the fault event cache layer, the method further comprises: Real-time monitoring of the number of caches in the fault event cache layer; when the number of caches meets a preset cache capacity threshold, determining a fault event level corresponding to the fault event cache layer; Based on the fault event level, determining a minimum retention period threshold corresponding to the cache vector in the fault event cache layer, to manage the cache vector based on the minimum retention period threshold.

5. The public transportation demand response method based on a failure event according to claim 1, characterized by, Upon triggering of a decision request of the large model, performing vector query in the fault event cache layer to determine a demand hit vector, specifically comprising: According to the fault event, performing matching in the fault event cache layer to determine at least one independent cache space in the fault event cache layer; Obtaining decision request information of the large model, wherein the decision request information comprises a decision type, and the decision type comprises a single-point connection scheduling type and a line cooperative optimization type; Based on the decision type, performing vector query in the at least one independent cache space to determine a demand hit vector.

6. A public transportation demand response method based on a fault event according to claim 5, characterized in that, based on the decision type, performing vector query in the at least one independent cache space to determine a demand hit vector, specifically comprising: based on the decision type, matching a corresponding spatio-temporal value calculation operator to determine a vector spatio-temporal value by performing spatio-temporal value calculation on each of the event spatio-temporal encoding vectors through the spatio-temporal value calculation operator; based on the vector spatio-temporal value and a preset spatio-temporal value threshold, performing vector query in the at least one independent cache space to determine a demand hit vector.

7. A public transportation demand response method based on a fault event according to claim 5, characterized in that, based on the fault event, performing matching in the fault event cache layer to determine at least one independent cache space in the fault event cache layer, specifically comprising: based on a fault event identifier of the fault event, performing identifier matching in the fault event cache layer, and when there is a matching independent cache space corresponding to the fault event identifier, determining the independent cache space corresponding to the fault event with the matching independent cache space; based on the fault event identifier and a space identifier of each of the independent cache spaces in the fault event cache layer, performing similarity calculation to determine at least one independent cache space whose similarity meets a preset threshold.

8. A public transportation demand response method based on a fault event according to claim 6, characterized in that, based on the decision type, matching a corresponding spatio-temporal value calculation operator, specifically comprising: when the decision type is the single-point connection scheduling type, the spatio-temporal value calculation operator comprises a vector time efficiency parameter and a spatial tightness parameter; when the decision type is the line coordination optimization type, the spatio-temporal value calculation operator comprises a road network coverage rate parameter and a vector time efficiency parameter.

9. A public transportation demand response device based on a failure event, characterized by, The device comprises: at least one processor; and a memory connected in communication with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

10. A non-transitory computer storage medium storing computer-executable instructions, the computer-executable instructions comprising instructions for: receiving a request to access a file; determining whether the file is stored in a cache; and in response to determining that the file is stored in the cache, providing access to the file from the cache. The computer executable instructions are configured to perform the method of any one of claims 1-8.

Images