Game strategy retrieval method and device based on event-driven knowledge graph embedding

Abstract

This application provides a method and apparatus for game strategy retrieval based on event-driven knowledge graph embedding. The method includes: performing structured parsing of strategy data and updating entities and relationships; performing graph embedding calculations on entities and relationships in the knowledge graph to obtain vector representations between entities and constructing a searchable vector index; vectorizing the user's strategy query request and performing similarity retrieval with the vector index to obtain a first candidate entity set similar to the query vector; performing relational reasoning in the knowledge graph starting from the first candidate entity set to obtain a second candidate entity set semantically related to the first candidate entity set, and merging it with the first candidate entity set to form a target entity set; and ranking the target entity set by relevance to obtain the strategy results. This application can automatically and structuredly manage strategy data, supports deep semantic retrieval, thereby improving the accuracy of game strategy content retrieval and possessing dynamic expansion capabilities.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and apparatus for retrieving game strategies based on event-driven knowledge graph embedding. Background Technology

[0002] With the rapid growth of online game content, player communities have generated a massive amount of game guides (including level completion tips, equipment combinations, hidden elements, etc.). Existing guide platforms typically have the following characteristics: they are mainly stored in forum posts, long texts, or video links, lacking a unified data model. These platforms generally rely on full-text inverted indexes for keyword searches, with limited ability to handle synonyms, context, and cross-language content. When a new game or expansion is released, maintenance personnel need to manually create guide entries, category tags, and page templates, which is time-consuming and prone to omissions. Existing systems struggle to identify implicit relationships between guides (such as the correspondence between dungeon mechanics and character talents) and cannot accurately sort results based on player history.

[0003] Therefore, the resulting technical problems include: players have difficulty quickly and accurately locating strategy content related to specific games, levels, or themes from a vast amount of information; the platform's expansion efficiency is low, with a significant time lag between the launch of a new game and the availability of searchable strategies; and the search results lack relevance and personalization, affecting user experience and retention rates. Summary of the Invention

[0004] In view of this, embodiments of this application provide a game strategy retrieval method and apparatus based on event-driven knowledge graph embedding, in order to solve the problems of existing technologies such as inability to accurately locate game strategy content, poor platform scalability, and insufficient accuracy of retrieval results.

[0005] A first aspect of this application provides a game strategy retrieval method based on event-driven knowledge graph embedding, comprising: upon receiving a trigger event indicating the addition of a new game, automatically generating game entities and strategy encyclopedia entries corresponding to the new game in the knowledge graph; acquiring strategy data related to the new game, performing structured parsing on the strategy data, and integrating the parsed strategy data into the knowledge graph to update entities and relationships; based on the updated knowledge graph, performing graph embedding calculations on entities and relationships in the knowledge graph to obtain vector representations between entities and constructing a searchable vector index; vectorizing the user's strategy query request and performing similarity retrieval with the vector index to obtain a first candidate entity set similar to the query vector; performing relationship reasoning in the knowledge graph starting from the first candidate entity set to obtain a second candidate entity set semantically related to the first candidate entity set, and merging it with the first candidate entity set to form a target entity set; sorting the target entity set by relevance to obtain strategy results, and outputting the strategy results to the user terminal.

[0006] A second aspect of this application provides a game strategy retrieval device based on event-driven knowledge graph embedding, comprising: a generation module, configured to automatically generate game entities and strategy encyclopedia entries corresponding to the new game in the knowledge graph after receiving a trigger event indicating a new game; a parsing module, configured to acquire strategy data related to the new game, perform structured parsing on the strategy data, and integrate the parsed strategy data into the knowledge graph to update entities and relationships; a calculation module, configured to perform graph embedding calculation on entities and relationships in the knowledge graph based on the updated knowledge graph, obtain vector representations between entities, and construct a searchable vector index; a retrieval module, configured to vectorize the user's strategy query request, perform similarity retrieval with the vector index, and obtain a first candidate entity set similar to the query vector; a reasoning module, configured to perform relationship reasoning in the knowledge graph starting from the first candidate entity set, obtain a second candidate entity set that has semantic association with the first candidate entity set, and merge it with the first candidate entity set to form a target entity set; and an output module, configured to sort the target entity set by relevance, obtain strategy results, and output the strategy results to the user terminal.

[0007] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0008] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0009] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0010] Upon receiving a trigger event indicating the addition of a new game, this application automatically generates game entities and strategy encyclopedia entries corresponding to the new game in the knowledge graph; acquires strategy data related to the new game, performs structured parsing on the strategy data, and integrates the parsed strategy data into the knowledge graph to update entities and relationships; based on the updated knowledge graph, performs graph embedding computation on the entities and relationships in the knowledge graph to obtain vector representations between entities and constructs a searchable vector index; vectorizes the user's strategy query request and performs similarity retrieval with the vector index to obtain a first candidate entity set similar to the query vector; performs relationship reasoning in the knowledge graph starting from the first candidate entity set to obtain a second candidate entity set semantically related to the first candidate entity set, and merges it with the first candidate entity set to form a target entity set; sorts the target entity set by relevance to obtain the strategy results, and outputs the strategy results to the user. This application can automatically and structuredly manage strategy data, supports deep semantic retrieval, thereby improving the accuracy of game strategy content retrieval and possessing dynamic expansion capabilities. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating the game strategy retrieval method based on event-driven knowledge graph embedding provided in an embodiment of this application;

[0013] Figure 2 This is a schematic diagram of the structure of the game strategy retrieval device based on event-driven knowledge graph embedding provided in the embodiments of this application;

[0014] Figure 3 It is a structural diagram of an electronic device provided in an embodiment of the present application. Detailed Implementation

[0015] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0016] To address the problem of users struggling to quickly and accurately find the content they want from a vast amount of game guides, this application provides a structured management and retrieval technology for game guides, enabling users to quickly and accurately find specific games, levels, or themes. The technical implementation of this application includes:

[0017] 1. Based on message queue technology, automatically create and associate encyclopedia entries when a new game is added;

[0018] 2. Based on xlrd and xlwt, identify user-uploaded Excel files and generate corresponding terms;

[0019] 3. A low-code platform was designed that allows users to determine the layout of encyclopedia entries by dragging and dropping.

[0020] In addition, based on the above technical approach, this application adds an intelligent retrieval mechanism based on knowledge graph semantic embedding.

[0021] Specifically, graph embedding algorithms (such as TransE, GraphSAGE, etc.) are used to map knowledge graph entities and relations to a low-dimensional continuous vector space to establish a semantic embedding model;

[0022] When a user enters search terms, the system uses semantic matching algorithms (such as cosine similarity and semantic distance matching) to quickly compare the query request with the embedding vectors of entities in the knowledge graph, accurately identify and return strategy information that is semantically similar to the user's query. It also supports graph relationship reasoning to help users discover strategy information that is implicitly related to the query, thus improving the search experience.

[0023] Furthermore, this application introduces intelligent and precise retrieval technology based on semantic retrieval and recommendation algorithms. This application utilizes deep semantic matching and user profile analysis, combined with multi-dimensional data, to achieve a more accurate and personalized strategy retrieval service.

[0024] The system incorporates strategy guide semantic embedding and fast indexing retrieval technology based on pre-trained language models; a personalized retrieval and recommendation mechanism driven by user behavior data; and an intelligent retrieval dialogue system based on user intent recognition, helping users accurately locate strategy guide content.

[0025] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0026] Figure 1 This is a flowchart illustrating the game strategy retrieval method based on event-driven knowledge graph embedding provided in an embodiment of this application. Figure 1 As shown, this game strategy retrieval method based on event-driven knowledge graph embedding can specifically include:

[0027] S101, after receiving a trigger event indicating the addition of a new game, automatically generate a game entity and strategy encyclopedia entry corresponding to the new game in the knowledge graph;

[0028] S102: Obtain strategy data related to the new game, perform structured parsing on the strategy data, and integrate the parsed strategy data into the knowledge graph to update entities and relationships;

[0029] S103, Based on the updated knowledge graph, perform graph embedding computation on the entities and relations in the knowledge graph to obtain vector representations between entities and construct a searchable vector index;

[0030] S104, Vectorize the user's strategy query request and perform a similarity search with the vector index to obtain the first candidate entity set that is similar to the query vector;

[0031] S105, Starting from the first candidate entity set in the knowledge graph, perform relational reasoning to obtain the second candidate entity set that has semantic association with the first candidate entity set, and merge it with the first candidate entity set to form the target entity set;

[0032] S106: Sort the target entity set by relevance to obtain the strategy results, and output the strategy results to the user terminal.

[0033] In some embodiments, upon receiving a trigger event indicating the addition of a new game, a game entity and strategy encyclopedia entry corresponding to the new game are automatically generated in the knowledge graph, including:

[0034] The triggered event is written to a preset event queue;

[0035] The knowledge graph construction module of the subscribed event queue performs idempotency verification on the triggered events and creates game entity nodes corresponding to the newly added games in the knowledge graph;

[0036] Generate a corresponding strategy encyclopedia entry identifier based on the game entity node, and write the strategy encyclopedia entry identifier as an attribute into the game entity node.

[0037] Specifically, the event queue uses a distributed message queue (such as Kafka, Pulsar, or RabbitMQ) that supports at least At-Least-Once delivery semantics, and a separate topic GameCreateTopic is configured for new game events.

[0038] Knowledge graph construction module: Deployed as a stateless microservice, it has three capabilities: event consumption, idempotent verification, and graph database writing.

[0039] Graph database: Select a database that supports attribute graph models (such as Neo4j or TigerGraph) to persist Game type entity nodes.

[0040] Furthermore, when the operator clicks "Add Game" and confirms submission on the backend management interface, the business service immediately encapsulates an event message containing fields such as the game's unique identifier GameID, game name, and timestamp.

[0041] The event message is written to GameCreateTopic. During the writing process, a single transaction is started to ensure that the event corresponding to the same GameID is written at most once.

[0042] The knowledge graph construction module continuously monitors GameCreateTopic. Whenever a new game event is consumed, it first performs an idempotency check in a distributed cache (such as Redis) based on the EventID.

[0043] If the same EventID already exists in the cache, it is considered a duplicate event and is discarded directly.

[0044] If the cache does not exist, the EventID is recorded and an expiration time is set to prevent concurrent duplicate processing.

[0045] Furthermore, through the graph database session, the "merge" write logic is executed: if a Game node with a matching GameID already exists in the graph, only the latest creation time in the node attributes is updated; if it does not exist, a new Game node is created and basic attributes such as GameID, game name, and creation time are written.

[0046] This write operation uses database atomic transactions to ensure that nodes are created or updated completely, avoiding the loss of some attributes.

[0047] Furthermore, the system calls an internal unique identifier generator (which can be based on the Snowflake algorithm or an auto-incrementing sequence from the database) to generate a WikiID.

[0048] Write the WikiID as an attribute into the wikiId field of the target Game node; if the platform uses multiple data sources, the WikiID can also be registered to the document service or static content storage simultaneously to reserve space for the encyclopedia page.

[0049] Furthermore, after successful writing, the knowledge graph construction module appends a WikiInitTopic message to the event queue, carrying only the GameID and WikiID, to prompt the subsequent encyclopedia initialization service to generate page templates.

[0050] If the graph database write fails or the network times out, the module will record the number of retries and try again according to the exponential backoff strategy. If the maximum number of retries is exceeded, an alarm will be pushed.

[0051] This embodiment features low latency; in a production environment, the average time from event writing to Game node creation completion is controlled within 40ms, meeting real-time database creation requirements. It also offers high consistency, with idempotent checks and database transactions ensuring that the same GameID corresponds to only one Game node and WikiID, eliminating duplicate database creation issues under concurrency. Furthermore, it boasts scalability, with both the event queue and knowledge graph construction modules being horizontally scalable, capable of supporting high-concurrency writes when launching a large number of new games.

[0052] Through the above embodiments, after a new game is submitted, the standardized creation of game entity nodes and the unique identifier binding of the strategy encyclopedia entry can be completed automatically, providing a unified and reliable entity benchmark for subsequent strategy data analysis, integration and retrieval, which significantly improves the expansion efficiency and data consistency of the strategy platform.

[0053] In some embodiments, the strategy data is structured and parsed, and the parsed strategy data is integrated into a knowledge graph to update entities and relationships, including:

[0054] According to the preset field entity mapping rules, the strategy data is converted into field value pairs corresponding to the entity attributes of the knowledge graph;

[0055] Based on a similarity threshold, the field value pairs are matched with existing entity nodes in the knowledge graph for similarity.

[0056] If the similarity meets the similarity threshold, the attribute information of the matched target entity node is updated; if the similarity does not meet the similarity threshold, a new entity node is created in the knowledge graph.

[0057] Based on the preset relationship type, the target entity node or newly created entity node is associated with the game entity node to complete the fusion and update of the knowledge graph.

[0058] Specifically, when the platform receives official or community strategy data files (such as tables, CSV, or JSON) for a newly launched game, it needs to quickly incorporate them into the existing knowledge graph to ensure that subsequent searches can cover multi-dimensional information such as levels, enemies, and drops.

[0059] First, the platform maintains a list of field entity mapping rules in advance, defining the correspondence between external data fields and knowledge graph entity attributes; before loading strategy data, the parsing module automatically reads the latest mapping rules and caches them in memory to ensure mapping consistency.

[0060] Furthermore, the parsing module scans the strategy data file line by line, converting each line of content into several "field value" pairs; it performs unified preprocessing on the text values ​​that need to be used for entity matching, including removing redundant punctuation, unifying capitalization, and merging homophones, in order to reduce matching errors caused by format differences.

[0061] Furthermore, the parsing module generates a standardized description for each entity to be written and calculates its similarity with existing entities of the corresponding type in the knowledge graph. The similarity score comprehensively considers factors such as edit distance, thesaurus, and semantic vector angle, and compares it with a preset threshold.

[0062] If the value exceeds the threshold: the match is considered successful, and the missing attribute is updated or supplemented in the target entity node;

[0063] If the value is below the threshold: it is identified as the first entry, and the graph database is called to write a new entity node, while the creation timestamp is recorded.

[0064] Furthermore, based on the platform's built-in relationship templates, the parsing module establishes semantic relationships between the updated or newly created entities and the corresponding game entity nodes, such as "contains level", "associated with enemy", "dropped items", etc.

[0065] Relationship writing adopts batch transaction mode to ensure that the relationships between nodes within the same batch are atomically consistent, avoiding the state of "nodes have been written but relationships are lost".

[0066] Furthermore, after the batch writing is completed, the parsing module generates a change summary, including the number of newly added entities, the number of updated entities, and low-similarity items that failed. If the proportion of low-similarity items exceeds a preset threshold, the system automatically triggers a manual review process and suspends subsequent writing of that batch to prevent the entry of noisy data. Version identifiers are set for the written entities so that traceability and rollback can be achieved when the guide content is updated in the future.

[0067] Key technical points and advantages of this embodiment include: hot loading of field entity mapping rules, supporting adjustments to mappings at any time without downtime deployment; comprehensive judgment of multi-indicator similarity, effectively improving matching accuracy and reducing false merging rate; batch transaction writing, ensuring consistency of nodes and relationships, and avoiding data silos; change summary and threshold alarm, providing automated risk control and manual backup for graph quality; versioned entities, facilitating differentiated rollback and time series analysis.

[0068] Through this embodiment, the platform can complete the structured parsing and graph fusion of strategy data within minutes, automatically maintain multi-layered entities such as strategies, games, and levels and their relationships, and provide accurate and real-time updated data support for subsequent graph embedding, semantic retrieval and personalized recommendations.

[0069] In some embodiments, based on the updated knowledge graph, graph embedding computation is performed on the entities and relationships in the knowledge graph to obtain vector representations between entities, and a searchable vector index is constructed, including:

[0070] Using a pre-defined graph embedding algorithm, the entities and relationships in the updated knowledge graph are embedded to obtain vector representations that characterize the semantic features of each entity.

[0071] Write the entity vector and its corresponding entity identifier into the vector index library, and build a vector index that supports similarity retrieval based on the approximate nearest neighbor retrieval structure;

[0072] When new or changed entities and relationships are detected in the knowledge graph, incremental embedding calculations are performed on the affected parts, and the vector index is updated synchronously.

[0073] Specifically, in this embodiment, after the platform completes the strategy data fusion, it periodically transmits the latest knowledge graph to the graph embedding computing service. This service runs on an independent computing cluster, uses a pre-selected graph embedding algorithm to perform low-dimensional vectorization representation of entities and relationships in the knowledge graph, and generates vector indexes that can be used for efficient similarity retrieval.

[0074] The platform uses a workflow scheduler to automatically launch a full embedding training task during the early morning hours when business is at a low peak. The task first pulls a snapshot of the graph database to ensure the consistency of the training data.

[0075] To ensure adaptability and interpretability for large-scale relational data, the platform chose a graph embedding algorithm based on translation distance as the default solution. With an ideal number of training epochs, it can effectively capture diverse semantic relationships between entities. Hyperparameters such as embedding dimension and learning rate were determined through cross-experiments before deployment and fixed in a configuration file for continuous reuse.

[0076] At the end of the training process, the service will generate a set of fixed-dimensional vector coordinates for each entity in the graph. The vector files, along with the entity identifiers, are synchronously pushed to the storage cluster for direct reading by the index building process.

[0077] In some examples, to balance query accuracy and response speed, the platform employs a hierarchical graph structure for an approximate nearest neighbor index. This structure's multi-level skip mechanism can quickly locate similar entities within the vector space, ensuring retrieval latency is in the millisecond range.

[0078] The index building task pairs the entity vectors output by the graph embedding service with the entity identifiers and writes them one-to-one into the index nodes. After writing is complete, the index nodes immediately provide an internal query interface for the retrieval module to call.

[0079] To prevent index read / write conflicts during the retrieval phase, the index building task uses a dual-replica strategy: one replica handles external services, while the other performs incremental updates. After the update is complete, seamless replacement is achieved through name switching.

[0080] Furthermore, the platform pre-configures event channels in the knowledge graph writing process. Whenever a new or modified entity is added, a change event is generated, containing a unique identifier of the changed entity.

[0081] The graph embedding computing service monitors the change event queue and aggregates them in mini-batch. Each time a preset number of entries is accumulated or a timeout threshold is reached, the corresponding subgraph is extracted for incremental training, outputting only the vectors of the affected entities.

[0082] After the incremental vector is generated, the index node loads the latest vector of the corresponding entity, overwrites and updates the original entry, and immediately refreshes the memory index structure after the write is completed to ensure the real-time nature of the search results.

[0083] This embodiment can improve training efficiency; under the current hardware configuration, full graph embedding training can be completed within one hour; reduce retrieval latency; the average response time for a single vector similarity query is no more than five milliseconds; improve update efficiency; newly added entities can obtain searchable vector representations within five minutes after being written into the graph; and has fault recovery function; if the training task terminates abnormally, the next scheduling will automatically restart from the most recent snapshot, and the index copy switching mechanism ensures that the retrieval service is not affected.

[0084] Through this embodiment, the platform can continuously maintain semantic vectors for each entity in the knowledge graph and achieve high-throughput, low-latency similarity retrieval with an approximate nearest neighbor index, providing a solid data foundation for subsequent semantic recall, relational reasoning, and result ranking.

[0085] In some embodiments, the user's strategy query request is vectorized and similarity retrieval is performed with the vector index to obtain a first candidate entity set similar to the query vector, including:

[0086] Receive strategy query requests from users;

[0087] Using a semantic encoding module, a pre-trained language model is used to convert strategy query requests into query vectors;

[0088] Call the vector retrieval module to perform an approximate nearest neighbor retrieval in the vector index based on the query vector, and calculate the similarity between the query vector and the entity vector;

[0089] Based on a preset similarity threshold or the top K high similarity rule, the first set of candidate entities similar to the query vector is obtained.

[0090] Specifically, when an end user enters text (e.g., "strategy for clearing Chapter 3") in the search box and clicks the search button, the front end immediately packages the text along with the user identifier, language information, and current timestamp into a query request and sends it to the backend semantic retrieval gateway. Upon receiving the request, the gateway performs preprocessing operations such as character set unification and removal of redundant whitespace and illegal characters to ensure that the encoding module can stably parse the statement.

[0091] The semantic encoding module loads a pre-trained language model that has been fine-tuned within the domain. This model has been additionally trained on game-related vocabulary and is able to more accurately capture proper nouns and verb phrases in the strategy context.

[0092] In some examples, the vectorization process includes the following:

[0093] First, the encoding module serializes the preprocessed text into the model input format and performs one forward inference;

[0094] Next, the sentence vector output by the model is processed by mean pooling and normalization to finally form a fixed-length, high-dimensional query vector;

[0095] The query vector is then appended with a unique request ID and pushed to the vector retrieval module within milliseconds.

[0096] Furthermore, for non-Chinese queries, the system uses a unified multilingual model branch. During vector space construction, it ensures that semantically similar content from different languages ​​is projected into nearby regions, thereby enabling cross-language retrieval.

[0097] In some examples, the platform’s vector index is implemented using a hierarchical graph structure, with nodes stored in main memory and accessed in read-only mode to meet TPS (transactions per second) requirements.

[0098] After receiving the query vector, the retrieval module accesses the entry layer of the graph according to the index parameters and searches downwards layer by layer. During the graph traversal, the system continuously compares the distance between the current node and the query vector and maintains a min-heap of candidate entities. Once the search reaches the preset depth or the upper limit of the number of accessed nodes, the traversal stops and the candidate list is returned.

[0099] Cosine similarity is used as the metric. To improve efficiency, the module normalizes the vectors, making them convertible to vector dot product operations in hardware.

[0100] In some examples, the retrieval module can filter the returned results according to the following two types of rules:

[0101] If the platform is configured with a fixed threshold, only entities with similarity higher than the threshold will be retained;

[0102] If no threshold is set, the top K entities by similarity will be returned. The value of K can be dynamically adjusted according to the business scenario.

[0103] To avoid duplicate appearances of the same entity due to language or aliases, the system performs entity identifier deduplication once during the candidate list formation stage, retaining only the version with the highest score.

[0104] The first set of candidate entities, after screening, along with their similarity scores, is returned to subsequent components in the recall layer via an internal protocol for further relational reasoning and ranking.

[0105] The latency metrics of this embodiment are as follows: In a scenario with thousands of concurrent users, the average time from receiving user text to producing the first candidate entity set is kept within 30 milliseconds; Accuracy guarantee: Through intra-domain fine-tuning and multilingual alignment, the recall phase can achieve a top-K coverage rate of over 97% on the public test set; Abnormal rollback: If the semantic encoding module times out, the gateway automatically rolls back to the keyword retrieval mode to ensure that users always get available results.

[0106] This embodiment achieves efficient vectorization and high-speed similarity retrieval of user natural language queries, providing a high-quality, low-latency first candidate entity set for subsequent relational reasoning and personalized ranking, thus meeting the dual requirements of game strategy platforms in terms of real-time performance and accuracy.

[0107] In some embodiments, relational reasoning is performed in the knowledge graph starting from a first candidate entity set to obtain a second candidate entity set that has semantic association with the first candidate entity set, including:

[0108] Load the preset inference rule set, which limits the types of relationships allowed for inference and the maximum number of hops;

[0109] For each entity node in the first candidate entity set, perform a graph traversal with a limited number of hops along the relation edges that conform to the inference rule set in the knowledge graph, and collect the entity nodes reached during the traversal.

[0110] The collected entity nodes are deduplicated and summarized to form a second candidate entity set that has a semantic relationship with the first candidate entity set.

[0111] Specifically, the knowledge graph storage layer is constructed using an attribute graph database, with nodes covering types such as "game—level—enemy—equipment—dropped items—skills—element attributes," and relationship edges modeled according to game semantics.

[0112] Inference Engine: Deployed as an independent microservice, responsible for loading inference rules, performing graph traversal, and producing an extended entity set.

[0113] Rule Configuration Center: Stores hot-updateable inference rule files, supporting version management and canary releases.

[0114] During the recall phase, the platform has obtained a first set of candidate entities based on the query request. The following steps describe how to infer a second set of candidate entities that are semantically related to this set from these entities.

[0115] Furthermore, when the inference engine starts, it pulls the currently effective rule files from the rule configuration center. A typical format includes:

[0116] Allowed relationship types for inference, such as: "includes enemies", "dropped items", "counter attributes", "unlock skills", and the maximum number of hops that each relationship can spread (e.g., all limited to two hops).

[0117] The rule file uses text descriptions, which are then converted into in-memory data structures for high-speed matching during the traversal phase. If operators update the rules, the configuration center pushes the change event, and the inference engine completes the hot replacement without restarting.

[0118] Furthermore, all entities in the first candidate entity set are written into the queue to be traversed, and a "current hop count" counter is associated with each entity, with an initial value of 0.

[0119] The inference engine adopts a breadth-first strategy: retrieve the entity node from the head of the queue and read its current hop count d; query all outgoing edges of the node and filter whether the edge type is in the allowed list of the rule set; if allowed and d+1≤ the maximum hop count of the corresponding relationship, add the target node to the result buffer and re-enqueue it with the hop count d+1.

[0120] During the traversal, the "visited set" is maintained in real time to avoid loops; the traversal ends when the queue is empty or all nodes have reached their respective hop count limits.

[0121] For example, in a specific scenario, if the first candidate entity contains a "final leader" node:

[0122] The first jump finds three rare material nodes along the "dropped items" relationship; at the same time, it reaches the fire element node along the "counter attribute" relationship; the second jump spreads the "fire element" node: find the special weapon node that can inflict ice damage along the reverse "counter attribute" relationship; since the maximum number of jumps is 2, the traversal stops here.

[0123] After the traversal is complete, the inference engine removes duplicate identifiers from all reached nodes in the buffer and filters out entities that already exist in the first candidate entity set.

[0124] The remaining nodes constitute the second set of candidate entities, covering multi-dimensional information such as boss drops, counter equipment, related attributes, and clearing skills.

[0125] In the example above, the second candidate entity set might include: rare materials M1, M2, and M3—used to craft high-level equipment; a fire element node—revealing the boss's weaknesses; an ice attribute weapon W1—effective against fire element; and a "Burst Impact" skill node—automatically unlocked after clearing a level. These entities are then merged with the first candidate entity set and placed into the sorting layer to provide users with a more complete strategy guide.

[0126] Performance and stability description of this embodiment:

[0127] Time overhead: After limiting the number of hops and filtering relationships, a single inference is completed in less than 10 milliseconds on average, and it will not become a bottleneck for retrieval even with thousands of concurrent users.

[0128] Memory usage: The number of nodes and relations accessed during the inference process is strictly limited by the number of hops, and it can run within a fixed memory budget.

[0129] The rules are extensible: If a "cooperative tactical" relationship is added in a later version of the game, it will take effect simply by adding a new entry to the rule set and specifying the number of jumps, without having to modify the traversal logic.

[0130] In this embodiment, the retrieval system, based on the original semantic recall results, expands the graph relationships in a limited and controllable manner to quickly supplement the strategy information that is closely related to the user's query topic but is difficult to directly hit through keywords, thus significantly improving the retrieval coverage and practical value.

[0131] In some embodiments, the target entity set is sorted by relevance to obtain the strategy results, including:

[0132] For each entity node in the target entity set, calculate the semantic similarity score between the entity node and the user query vector;

[0133] Obtain behavioral features related to user profiles, and calculate the corresponding user behavior feature score for each entity node in the target entity set;

[0134] According to the preset weighting rules, the semantic similarity score and the user behavior feature score are combined to obtain the comprehensive relevance score;

[0135] The target entity set is sorted based on the comprehensive relevance score to generate the strategy results.

[0136] Specifically, the retrieval system has obtained a fused set of target entities, which includes multi-dimensional entities such as boss strategies, counter weapons, dropped items, and level rewards. To ensure that the final strategy guides pushed to users are both semantically relevant to the query and match their personal interests and preferences, this set needs to be sorted by comprehensive relevance.

[0137] For each entity node in the target entity set, the retrieval service first extracts its semantic vector, which is in the same vector space as the user query vector; calculates the cosine value between the two vectors to obtain a semantic similarity score in the range of 0 to 1; for example, in one example, when a user queries "final boss strategy", the boss entity and the weapon that counters it usually get a semantic score higher than 0.9, while the level completion reward entity may only get 0.6.

[0138] Furthermore, the platform maintains a real-time profile for each user, including recent interaction records: frequently viewed entity categories (such as "weapons" or "dropped items"); unlocked or collected levels and equipment; preferred content formats (text, images, videos).

[0139] The ranking module generates a behavioral feature score for each entity in the set based on the profile matching degree. For example, in one example, if a user frequently clicks on entities of the "dropped items" category, then entities of that category will receive a bonus in this dimension.

[0140] Furthermore, the system uses a linear weighting method to synthesize the two types of scores into a comprehensive relevance score: semantic similarity accounts for 60% of the weight, emphasizing direct matching with the query topic; behavioral features account for 40% of the weight, used for personalized ranking; the weight ratio is determined by online experiments and can be dynamically adjusted through the configuration center to adapt to different business indicators.

[0141] Furthermore, the target entity set is sorted from highest to lowest based on the overall score; the top N items (e.g., 20 items) are used to generate the final strategy results, and a display template is selected based on the entity type, for example:

[0142] If the entity is a "weapon", the front end will prioritize displaying its acquisition method and attribute panel;

[0143] If the entity is a "dropped item", it will include the drop probability and its crafting uses;

[0144] If the entity is a "level mechanism", provide illustrations and key operation steps.

[0145] For example, in one instance, different users might see the same query in a different order: novice users would see "Gameplay Steps" and "Weakness Analysis" first, while advanced players would see "Efficient Weapons for Speed ​​Farming" and "Rare Drops" earlier.

[0146] This embodiment features real-time performance: the comprehensive sorting is completed in server-side memory, with an average time of less than 5 milliseconds, ensuring smooth overall search response; interpretability: two sub-scores are recorded for each final result, which can be used for front-end floating prompts or log analysis to improve system transparency; dynamic learning: the weights of behavioral features are automatically fine-tuned based on recent clicks, dwell times, and favorites signals to achieve continuously optimized personalized effects.

[0147] Through this embodiment, the platform can accurately and personally rank multi-source candidate entities within milliseconds, outputting strategy results that fit the query context and personal interests to users, greatly improving search effectiveness and user satisfaction.

[0148] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0149] Figure 2 This is a schematic diagram of the structure of the game strategy retrieval device based on event-driven knowledge graph embedding provided in an embodiment of this application. Figure 2 As shown, the game strategy retrieval device based on event-driven knowledge graph embedding includes:

[0150] The generation module 201 is used to automatically generate game entities and strategy encyclopedia entries corresponding to the new game in the knowledge graph after receiving a trigger event indicating the addition of a new game.

[0151] The parsing module 202 is used to obtain strategy data related to the new game, perform structured parsing on the strategy data, and integrate the parsed strategy data into the knowledge graph to update entities and relationships;

[0152] The computation module 203 is used to perform graph embedding computation on entities and relations in the updated knowledge graph to obtain vector representations between entities and to construct a searchable vector index.

[0153] The retrieval module 204 is used to vectorize the user's strategy query request and perform similarity retrieval with the vector index to obtain the first candidate entity set similar to the query vector;

[0154] The reasoning module 205 is used to perform relational reasoning in the knowledge graph starting from the first candidate entity set, to obtain the second candidate entity set that has semantic association with the first candidate entity set, and to merge it with the first candidate entity set to form the target entity set;

[0155] Output module 206 is used to sort the target entity set by relevance, obtain the strategy results, and output the strategy results to the user terminal.

[0156] In some embodiments, Figure 2 The generation module 201 writes the triggered event into a preset event queue; the knowledge graph construction module that subscribes to the event queue performs idempotency verification on the triggered event and creates a game entity node corresponding to the newly added game in the knowledge graph; the corresponding strategy encyclopedia entry identifier is generated based on the game entity node, and the strategy encyclopedia entry identifier is written as an attribute into the game entity node.

[0157] In some embodiments, Figure 2 The parsing module 202 converts the strategy data into field value pairs corresponding to the entity attributes of the knowledge graph according to the preset field entity mapping rules; it performs similarity matching between the field value pairs and the existing entity nodes in the knowledge graph according to the similarity threshold: if the similarity meets the similarity threshold, the attribute information of the matched target entity node is updated; if the similarity does not meet the similarity threshold, a new entity node is created in the knowledge graph; according to the preset relationship type, the target entity node or the newly created entity node is associated with the game entity node to complete the fusion and update of the knowledge graph.

[0158] In some embodiments, Figure 2 The computation module 203 uses a preset graph embedding algorithm to perform embedding calculations on entities and relationships in the updated knowledge graph to obtain vector representations of the semantic features of each entity; writes the entity vectors and corresponding entity identifiers into the vector index library, and constructs a vector index that supports similarity retrieval based on the approximate nearest neighbor retrieval structure; when new or changed entities and relationships are detected in the knowledge graph, incremental embedding calculations are performed on the affected parts, and the vector index is updated synchronously.

[0159] In some embodiments, Figure 2 The retrieval module 204 receives the strategy query request input by the user; using the semantic encoding module, the strategy query request is converted into a query vector through a pre-trained language model; the vector retrieval module is called to perform an approximate nearest neighbor retrieval in the vector index based on the query vector, and the similarity between the query vector and the entity vector is calculated; according to the preset similarity threshold or the top K high similarity rule, the first candidate entity set similar to the query vector is selected.

[0160] In some embodiments, Figure 2 The reasoning module 205 loads a preset reasoning rule set, which limits the types of relations allowed for reasoning and the maximum number of hops. For each entity node in the first candidate entity set, a graph traversal with a limited number of hops is performed along the relation edges that conform to the reasoning rule set in the knowledge graph, and the entity nodes reached during the traversal are collected. The collected entity nodes are deduplicated and summarized to form a second candidate entity set that has a semantic relationship with the first candidate entity set.

[0161] In some embodiments, Figure 2The output module 206 calculates the semantic similarity score between the entity node and the user query vector for each entity node in the target entity set; obtains behavioral features related to the user profile, and calculates the corresponding user behavior feature score for each entity node in the target entity set; combines the semantic similarity score and the user behavior feature score according to a preset weighting rule to obtain a comprehensive relevance score; sorts the target entity set according to the comprehensive relevance score to generate the strategy results.

[0162] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0163] Figure 3 This is a schematic diagram of the structure of the electronic device 3 provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 3 of this embodiment includes a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0164] For example, computer program 303 may be divided into one or more modules / units, which are stored in memory 302 and executed by processor 301 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 303 in electronic device 3.

[0165] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0166] Processor 301 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0167] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 302 can include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0168] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0169] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0170] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0171] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0172] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0173] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0174] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0175] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A game strategy retrieval method based on event-driven knowledge graph embedding, characterized in that, include: Upon receiving a trigger event indicating the addition of a new game, the system automatically generates a game entity and strategy encyclopedia entry corresponding to the new game in the knowledge graph. Acquire strategy data related to the newly added game, perform structured parsing on the strategy data, and integrate the parsed strategy data into the knowledge graph to update entities and relationships; Based on the updated knowledge graph, graph embedding computation is performed on the entities and relations in the knowledge graph to obtain vector representations between entities and to construct a searchable vector index. The user's strategy query request is vectorized and similarity search is performed with the vector index to obtain the first candidate entity set similar to the query vector; In the knowledge graph, relational reasoning is performed starting from the first candidate entity set to obtain a second candidate entity set that has semantic association with the first candidate entity set, and then merged with the first candidate entity set to form the target entity set; The target entity set is sorted by relevance to obtain the strategy results, and the strategy results are output to the user terminal; The platform employs a hierarchical graph structure for approximate nearest neighbor indexing. The multi-level skipping mechanism of the hierarchical graph structure can quickly locate similar entities in the vector space. The index building task uses a dual-replica strategy, with one replica responsible for external services and the other replica performing incremental updates. After the update is completed, seamless replacement is achieved through name switching. The platform pre-configures event channels in the knowledge graph writing process; the graph embedding computing service monitors the change event queue and aggregates them in small batches; each time a preset number of entries or a timeout threshold is accumulated, the corresponding subgraph is extracted for incremental training, and only the vectors of the affected entities are output. After the incremental vector is generated, the index node loads the latest vector of the corresponding entity, overwrites and updates the original entry, and immediately refreshes the memory index structure after the write is completed to ensure the real-time nature of the retrieval results.

2. The method according to claim 1, characterized in that, Upon receiving a trigger event indicating the addition of a new game, the system automatically generates a game entity and strategy encyclopedia entry corresponding to the new game in the knowledge graph, including: Write the triggered event into a preset event queue; The knowledge graph construction module that subscribes to the event queue performs idempotency verification on the triggered event and creates a game entity node corresponding to the newly added game in the knowledge graph; Based on the game entity node, a corresponding strategy encyclopedia entry identifier is generated, and the strategy encyclopedia entry identifier is written as an attribute into the game entity node.

3. The method according to claim 1, characterized in that, The process of performing structured parsing on the strategy data and integrating the parsed strategy data into the knowledge graph to update entities and relationships includes: According to the preset field entity mapping rules, the strategy data is converted into field value pairs corresponding to the entity attributes of the knowledge graph; The field value pairs are matched with existing entity nodes in the knowledge graph based on a similarity threshold: If the similarity meets the similarity threshold, the attribute information of the matched target entity node is updated; if the similarity does not meet the similarity threshold, a new entity node is created in the knowledge graph. According to the preset relationship type, the target entity node or newly created entity node is associated with the game entity node to complete the fusion and update of the knowledge graph.

4. The method according to claim 1, characterized in that, Based on the updated knowledge graph, graph embedding computation is performed on the entities and relationships in the knowledge graph to obtain vector representations between entities, and a searchable vector index is constructed, including: Using a pre-defined graph embedding algorithm, the entities and relationships in the updated knowledge graph are embedded to obtain vector representations that characterize the semantic features of each entity. Write the entity vector and its corresponding entity identifier into the vector index library, and build a vector index that supports similarity retrieval based on the approximate nearest neighbor retrieval structure; When new or changed entities and relationships are detected in the knowledge graph, incremental embedding calculations are performed on the affected parts, and the vector index is updated synchronously.

5. The method according to claim 1, characterized in that, The step of vectorizing the user's strategy query request and performing a similarity search with the vector index to obtain a first candidate entity set similar to the query vector includes: Receive strategy query requests from users; Using a semantic encoding module, the strategy query request is converted into a query vector through a pre-trained language model; The vector retrieval module is invoked to perform an approximate nearest neighbor retrieval in the vector index based on the query vector, and the similarity between the query vector and the entity vector is calculated. Based on a preset similarity threshold or the top K high similarity rule, a first set of candidate entities similar to the query vector is obtained.

6. The method according to claim 1, characterized in that, The step of performing relational reasoning in the knowledge graph, starting from the first candidate entity set, to obtain a second candidate entity set that has semantic association with the first candidate entity set, includes: Load a preset inference rule set, which limits the types of relationships allowed for inference and the maximum number of hops; For each entity node in the first candidate entity set, a graph traversal with a limited number of hops is performed along the relation edges that conform to the inference rule set in the knowledge graph, and the entity nodes reached during the traversal are collected. The collected entity nodes are deduplicated and summarized to form a second candidate entity set that has a semantic relationship with the first candidate entity set.

7. The method according to claim 1, characterized in that, The process of ranking the target entity set by relevance to obtain the strategy results includes: For each entity node in the target entity set, calculate the semantic similarity score between the entity node and the user query vector; Obtain behavioral features related to user profiles, and calculate the corresponding user behavior feature score for each entity node in the target entity set; According to the preset weighting rules, the semantic similarity score and the user behavior feature score are combined to obtain a comprehensive relevance score; The target entity set is sorted according to the comprehensive relevance score to generate the strategy results.

8. A game strategy retrieval device based on event-driven knowledge graph embedding, characterized in that, include: The generation module is used to automatically generate game entities and strategy encyclopedia entries corresponding to the new game in the knowledge graph after receiving a trigger event indicating the addition of a new game. The parsing module is used to acquire strategy data related to the newly added game, perform structured parsing on the strategy data, and integrate the parsed strategy data into the knowledge graph to update entities and relationships; The computation module is used to perform graph embedding computation on entities and relationships in the updated knowledge graph, obtain vector representations between entities, and construct a searchable vector index. The retrieval module is used to vectorize the user's strategy query request and perform a similarity search with the vector index to obtain a first set of candidate entities similar to the query vector. The reasoning module is used to perform relational reasoning in the knowledge graph starting from the first candidate entity set to obtain a second candidate entity set that has a semantic relationship with the first candidate entity set, and merge it with the first candidate entity set to form a target entity set. The output module is used to sort the target entity set by relevance, obtain the strategy results, and output the strategy results to the user terminal. The platform employs a hierarchical graph structure for its approximate nearest neighbor index. This hierarchical graph structure's multi-level skipping mechanism enables rapid identification of similar entities within the vector space. The index building task utilizes a dual-replica strategy: one replica handles external services while the other performs incremental updates. After the update is complete, seamless replacement is achieved through name switching. The platform pre-configures an event channel within the knowledge graph writing process. The graph embedding computing service monitors the change event queue and aggregates it in small batches. Upon accumulating a preset number of entries or reaching a timeout threshold, the corresponding subgraph is extracted for incremental training, outputting only the vectors of affected entities. After the incremental vectors are generated, the index nodes load the latest vectors of the corresponding entities, overwriting and updating the original entries. The in-memory index structure is refreshed immediately after the writing process to ensure the real-time nature of the retrieval results.

9. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images