A method and apparatus for retrieving game strategies based on knowledge graph structured management

Abstract

The application provides a game strategy retrieval method and device based on knowledge graph structured management. The method comprises the following steps: reading a structured file uploaded by a user and containing game strategy information, analyzing fields in the structured file, and mapping the fields to corresponding term data; writing the term data into a database, constructing entity objects and semantic relationships corresponding to the term data, and encapsulating the entity objects and semantic relationships as update request messages; in response to the update request messages, incrementally updating knowledge graph data according to a predefined knowledge graph mode; based on the knowledge graph data, combining keywords and filtering conditions input by a user, performing semantic level analysis, determining a retrieval target entity and related terms, and outputting game strategy content and associated information related to the keywords. The application can improve retrieval efficiency and the accuracy of retrieval results, and improve the systematic management and structural degree of game strategy content.

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 knowledge graph structured management. Background Technology

[0002] With the rapid development of the digital game industry, game content is becoming increasingly rich and complex, and players' demand for game guides continues to grow. A large number of game guides are scattered across various platforms in the form of text, images, and videos, but they lack a unified organizational method and structured management, resulting in inefficient searching for specific levels, characters, or quests, leading to a poor user experience.

[0003] In existing technologies, some platforms centrally organize strategy content by creating game encyclopedias, but the following problems still exist: the collection and input of strategy content mainly rely on manual editing, which is inefficient, highly repetitive, and difficult to maintain structural consistency; there is a lack of systematic data structure, and strategy content usually exists in a flat text format, which is not conducive to refined management and subsequent correlation mining; content updates lack a mechanism to support them, and dynamic synchronization of game entries and related data cannot be achieved; when users search for strategy guides, they can only rely on keyword matching and cannot perform hierarchical searches based on the semantic relationships of game content; the page display method depends on front-end development, and ordinary users cannot customize the page structure and display style, resulting in a high editing threshold. Summary of the Invention

[0004] In view of this, the present application provides a game strategy retrieval method and apparatus based on knowledge graph structured management to solve the problems of low retrieval efficiency, lack of systematic management of strategy content, low degree of information structuring, and inaccurate retrieval results in the prior art.

[0005] A first aspect of this application provides a game strategy retrieval method based on knowledge graph structured management, comprising: responding to a request for new game information, constructing a data object containing basic attributes of the new game, encapsulating the data object as a message, and sending it to a backend system via a message queue to trigger an encyclopedia entry initialization operation; reading a structured file containing game strategy information uploaded by a user, parsing the fields in the structured file, and mapping the fields to corresponding entry data; writing the entry data into a database, constructing entity objects and semantic relationships corresponding to the entry data, and encapsulating the entity objects and semantic relationships as an update request message; responding to the update request message, incrementally updating the knowledge graph data according to a predefined knowledge graph pattern, creating or updating game-related entity nodes and semantic relationships between entity nodes; providing a visual editing interface for users to configure the encyclopedia page structure by dragging and dropping, and generating a page rendering configuration file associated with the entry data; and performing semantic hierarchical parsing based on the knowledge graph data, combined with user-input keywords and filtering conditions, determining the target entity and related entries for retrieval, and outputting game strategy content and related information semantically related to the keywords.

[0006] A second aspect of this application provides a game strategy retrieval device based on knowledge graph structured management, comprising: a construction module, configured to respond to a request for new game information, construct a data object containing basic attributes of the new game, encapsulate the data object as a message, and send it to a backend system via a message queue to trigger an encyclopedia entry initialization operation; a parsing module, configured to read a structured file containing game strategy information uploaded by a user, parse the fields in the structured file, and map the fields to corresponding entry data; and an encapsulation module, configured to write the entry data into a database, construct entity objects and semantic relationships corresponding to the entry data, and encapsulate the entity objects and semantic relationships. The system is encapsulated as an update request message; the update module, in response to the update request message, incrementally updates the knowledge graph data according to a predefined knowledge graph pattern, creating or updating game-related entity nodes and semantic relationships between entity nodes; the generation module, based on the generated term data and entity information, provides a visual editing interface for users to configure the encyclopedia page structure by dragging and dropping, and generates a page rendering configuration file associated with the term data; the output module, based on the knowledge graph data and combined with user-input keywords and filtering conditions, performs semantic hierarchical parsing, determines the target entity and related terms, and outputs game strategy content and related information semantically related to the keywords.

[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] In response to requests for new game information, this application constructs a data object containing the basic attributes of the new game, encapsulates the data object as a message, and sends it to the backend system via a message queue to trigger encyclopedia entry initialization. It reads a structured file containing game strategy information uploaded by the user, parses the fields in the structured file, and maps the fields to corresponding entry data. The entry data is written to a database, constructing entity objects and semantic relationships corresponding to the entry data, and encapsulating the entity objects and semantic relationships as an update request message. In response to the update request message, it incrementally updates the knowledge graph data according to a predefined knowledge graph pattern, creating or updating game-related entity nodes and the semantic relationships between entity nodes. Based on the generated entry data and entity information, it provides a visual editing interface for users to configure the encyclopedia page structure by dragging and dropping, generating a page rendering configuration file associated with the entry data. Based on the knowledge graph data, combined with user-input keywords and filtering conditions, it performs semantic hierarchical parsing to determine the target entities and related entries, outputting game strategy content and related information semantically related to the keywords. This application can improve retrieval efficiency and the accuracy of retrieval results, and enhance the systematic management and structuring of game strategy content. 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 knowledge graph structured management 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 knowledge graph structured management provided in this application embodiment;

[0014] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this 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] In the current gaming industry, with the continuous emergence of popular games and niche genres, a massive amount of game strategy content has been generated on the market. For ordinary users, after acquiring a vast amount of strategy information, it is often difficult to quickly and accurately find the specific level, character, equipment, or other information they need. This places higher demands on the information management and retrieval of game strategies, requiring a more efficient and intuitive way to organize and present strategy content.

[0017] The following methods are commonly used in existing technologies to retrieve information such as game guides:

[0018] Manual maintenance of encyclopedias / forums: The common practice is for game developers or community users to manually edit encyclopedias / wikis based on platforms such as forums and wikis. However, updates are not timely and the level of structure is low.

[0019] Keyword search: Most of the time, it relies on simple fuzzy searches using only keywords or titles; when the strategy system is large, the search accuracy is low, and it is difficult to present complex contextual relationships in the results (such as the relationship between characters and equipment, levels and tasks).

[0020] However, existing technologies still have the following drawbacks:

[0021] Information fragmentation: Strategy guides are stored in the form of scattered texts, images, etc., lacking systematic management;

[0022] Poor scalability: When the game is updated or a new version is released, a lot of repetitive work is required to maintain the strategy information;

[0023] Lack of relevance: It is difficult to intuitively display the hierarchy or relationship of "level-character-equipment-quest", which is not conducive to users' quick location or comparison;

[0024] Synchronization difficulties across multiple channels: If you need to maintain strategy content on multiple platforms (PC web pages, apps, communities), you often need to manually enter the information multiple times, which can easily lead to redundancy or inconsistency.

[0025] Therefore, in view of the problems existing in the prior art, this application proposes a structured management and retrieval technology solution for game guides. The overall implementation of this technical solution includes: using a message queue for event decoupling; upon detecting requests such as "add game" or "update game information," the system automatically creates or updates the corresponding encyclopedia entries and notifies the knowledge graph maintenance module for incremental updates. Based on Excel read / write tools (xlrd, xlwt), it supports users to batch generate or update information such as games, levels, characters, equipment, and items by uploading Excel files, achieving structured data entry for large-scale data. It leverages a low-code platform to achieve visual drag-and-drop layout, allowing users to flexibly configure and adjust the game encyclopedia page layout without professional front-end development, significantly improving editing efficiency. It constructs a structured knowledge graph management system for game guides, unifying game entities and relationship types through predefined graph schemas, achieving efficient graph-based retrieval and association analysis.

[0026] Before describing the technical solution of this application in detail, the following section provides a detailed explanation of the system architecture involved in the game strategy retrieval method based on knowledge graph structured management in a practical scenario, using specific examples. The system functions of this application can be divided into the following four main modules according to business logic: a game encyclopedia management module, an Excel file parsing module, a knowledge graph maintenance module, and a low-code editing module. In addition, there are supporting components such as a search engine / retrieval module and a database (or graph database).

[0027] I. Game Encyclopedia Management Module

[0028] It is used to receive requests for "adding a game" or "updating game information"; it is responsible for encapsulating relevant information into message objects and pushing them to the message queue; it provides interfaces for adding, modifying, deleting, and querying the game encyclopedia for use by the front end or other modules.

[0029] II. Excel File Parsing Module

[0030] The system reads user-uploaded Excel files using xlrd and validates the data table structure and content. After parsing, it extracts key fields (such as game name, level name, character, equipment, items, etc.) and uses xlwt or a corresponding database writing tool to generate or update the corresponding terms. The parsed information is also sent to the knowledge graph maintenance module in a synchronized manner to update entities and relationships.

[0031] III. Knowledge Graph Maintenance Module

[0032] It includes knowledge graph storage and management functions, and can use graph databases (such as Neo4j, ArangoDB or Titan) or use relational databases to simulate graph structures;

[0033] It includes graph update triggers and incremental knowledge graph update algorithms: after receiving messages such as "add game" or "update strategy information" pushed from the message queue, it automatically performs incremental updates to dynamically maintain entities such as games, levels, and characters and their relationships;

[0034] By using predefined schemas, we can ensure the uniformity and standardization of various entity types and relationship types within the game domain.

[0035] IV. Low-code editing module

[0036] It provides users with a visual drag-and-drop component for layout and arrangement of encyclopedia pages; it combines layout configuration with entry information to automatically generate the final visual encyclopedia page; it can be linked with the encyclopedia management module to achieve a WYSIWYG encyclopedia content display.

[0037] In addition, it also includes a search and retrieval module to provide keyword-based indexing and knowledge graph-based semantic search; combined with the knowledge graph maintenance module, it can achieve more refined retrieval and related recommendations according to hierarchical structures such as "game-level-character-equipment".

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

[0039] Figure 1 This is a flowchart illustrating the game strategy retrieval method based on knowledge graph structured management provided in this application embodiment. Figure 1 As shown, this game strategy retrieval method based on knowledge graph structured management can specifically include:

[0040] S101, in response to the request for new game information, constructs a data object containing the basic attributes of the new game, encapsulates the data object as a message, and sends it to the backend system through the message queue to trigger the encyclopedia entry initialization operation;

[0041] S102: Read the structured file containing game strategy information uploaded by the user, parse the fields in the structured file, and map the fields to the corresponding term data;

[0042] S103, write the term data into the database, construct the entity objects and semantic relationships corresponding to the term data, and encapsulate the entity objects and semantic relationships into an update request message;

[0043] S104, in response to the update request message, incrementally update the knowledge graph data according to the predefined knowledge graph pattern, and create or update game-related entity nodes and semantic relationships between entity nodes;

[0044] S105 provides a visual editing interface based on the generated term data and entity information, allowing users to configure the encyclopedia page structure by dragging and dropping, and generating a page rendering configuration file associated with the term data;

[0045] S106, based on knowledge graph data, combined with user-input keywords and filtering conditions, performs semantic hierarchical parsing to determine the target entity and related terms, and outputs game strategy content and related information that are semantically related to the keywords.

[0046] In some embodiments, sending a message to the backend system via a message queue to trigger the encyclopedia entry initialization operation includes:

[0047] The message is sent to a preset message queue to enable asynchronous communication between the front-end request processing module and the back-end encyclopedia processing module;

[0048] In the backend encyclopedia processing module, listen to the message queue. When a message is received, automatically execute the initialization operation of the encyclopedia entry. After the encyclopedia entry initialization is completed, generate entry identification information and record the initialization status.

[0049] The initialization process for encyclopedia entries includes creating a main entry in the database corresponding to the newly added game and writing the main entry into the basic attribute information of the newly added game.

[0050] Specifically, in this embodiment, for scenarios where a user submits a "new game" request or obtains new game data from a third-party API, a message queue is used to achieve asynchronous communication between the front-end request processing module and the back-end encyclopedia processing module, thereby triggering the initialization operation of the encyclopedia entry. The specific implementation process is as follows:

[0051] First, when a user actively submits a "Add Game" request on the front-end interface, or when the system receives new game data from a third-party API, the front-end request processing module will detect the "Add Game" event and obtain basic attribute data, including game name, platform information, initial description, release time, etc., from the user or the third party.

[0052] To facilitate subsequent transmission and processing, the front-end request processing module can organize the above-mentioned basic game attribute data into a data object (such as a JSON object), which includes necessary fields such as "game name", "platform", and "publisher".

[0053] Furthermore, the front-end request processing module (or game encyclopedia management module) further encapsulates the data object into a message object; in this embodiment, a unique identifier and metadata fields describing the operation type can be specified for the message object, for example:

[0054] Message type: for example, "GameCreation";

[0055] Basic attributes include game name, initial description, release date, etc.

[0056] Other necessary markers: such as source channel, current timestamp, etc.

[0057] Push the message object to a pre-configured message queue (named "GameCreationQueue" in this example) to enable asynchronous communication with the backend encyclopedia processing module.

[0058] Furthermore, in the backend system, the encyclopedia processing module continuously monitors "GameCreationQueue"; once a new message is detected entering the queue, it automatically pops (or consumes) the message.

[0059] This listening operation is usually implemented through polling or event-driven methods. The specific implementation details can be determined according to the type of message queue (such as RabbitMQ, Kafka, etc.), but the essential goal is to immediately trigger the initialization process of the encyclopedia entry once a new game message appears.

[0060] Furthermore, after retrieving the message, the encyclopedia processing module will first verify and parse the basic game attribute data in the message to confirm the integrity and validity of the data; if the data is incomplete or abnormal, the error information can be written to the log or fed back to the upper-level calling interface.

[0061] After confirming the data is correct, the encyclopedia processing module will create a main entry corresponding to the newly added game in the database. For example:

[0062] Create a new record in the encyclopedia database: For example, insert a new record into the "game_encyclopedia" or "wiki_entries" table, and the record content includes the game name, initial description, and related attributes (such as "publisher" and "platform information").

[0063] Generate main term identifier information: The system can generate a unique term identifier (such as "EntryID" or "GameID") based on the database auto-incrementing primary key or UUID; this identifier will be used for subsequent retrieval and association operations.

[0064] Record the initialization status: In the same data record or a related status table, write a flag such as "Created" or "Initialization successful". This step facilitates subsequent queries to see if the encyclopedia entry has completed initialization.

[0065] Furthermore, once the encyclopedia entry initialization operation is completed, the encyclopedia processing module can write the operation result information (such as the newly created entry ID, initialization success flag, timestamp, etc.) to a log file for system operation or technical personnel to audit and trace.

[0066] If it is necessary to call the upper layer to return results, the encyclopedia processing module can also encapsulate a response message including "entry identification information" and "creation status," and provide feedback through a specific interface or receipt message. For example:

[0067] The response format can be JSON, including fields such as "success" and "entry_id".

[0068] If the automation process needs to be expanded in the future, the success message can be written to the message queue again to notify other relevant modules (such as notifying the low-code editing module to update the UI display).

[0069] Furthermore, in some examples, the initialization of encyclopedia entries only involves creating and recording the main entry for the newly added game. If it is necessary to continue maintaining information on levels, characters, equipment, or other entries for the game later, the same message queue mechanism can be used, or the incremental update interface of the backend encyclopedia management module can be directly called.

[0070] If the system detects that the newly added game does not have a corresponding game entity node in the knowledge graph, it can automatically send an update request message for "new game entity" to the knowledge graph maintenance module after completing the encyclopedia initialization, thereby triggering an incremental update operation of the graph database. However, this content belongs to the technical aspects involved in other implementation methods and is not within the scope of this embodiment.

[0071] As can be seen from the above embodiments, the technical solution of this application introduces a message queue as an asynchronous decoupling method, which can effectively reduce the real-time coupling between front-end requests and back-end encyclopedia initialization operations, thereby improving the stability and scalability of the system. When a new game information request arrives, the back-end can promptly trigger and complete the initialization of the encyclopedia entry based on the message queue, avoiding blocking of the front-end or other modules due to waiting, and effectively improving the overall processing efficiency. The above specific embodiments are highly flexible in implementation and are equally applicable to game encyclopedia systems of different sizes or types.

[0072] In some embodiments, a structured file containing game strategy information uploaded by a user is read, the fields in the structured file are parsed, and the fields are mapped to corresponding term data, including:

[0073] Receive structured files uploaded by users through the front-end interface or API, and store the structured files in a temporary storage path;

[0074] Perform format validation on structured files. The validation includes file structure, header field naming, data type and integrity. If the validation fails, return an error message.

[0075] After the verification is passed, the data content in the structured file is parsed to extract multiple fields related to the game;

[0076] Based on the mapping rules between fields and system-predefined term types, the extracted field content is converted into the corresponding term data structure.

[0077] Specifically, users upload an Excel file containing game guides via a front-end interface or API (which can be uploaded automatically by a script or manually by the user). The Excel file includes multiple fields such as level name, character, equipment, items, and guide text. After receiving the file, the system temporarily stores it in a specified storage path on the server (e.g., / temp / uploads / ) and generates a unique filename to locate the file during subsequent parsing.

[0078] Before parsing begins, the system performs basic format checks on the Excel file, including the following:

[0079] Sheet quantity or name: such as whether a main sheet is included, or at least one valid data sheet exists;

[0080] Header field naming: For example, the first row should be "Game Name", "Level Name", "Character", "Mission Name", "Reward Description", etc.;

[0081] Data type and integrity: such as some columns should be strings, some columns should be date or numeric formats, and perform integrity checks on the entire row or column.

[0082] If the validation fails (e.g., a required field is missing from the table header, or the data format does not match expectations), the system will immediately return an error message and terminate the subsequent parsing process.

[0083] Furthermore, after confirming that the file passes format verification, the system calls the xlrd library (or other alternative Excel parsing tools) to parse the worksheet content:

[0084] Read line by line: Read each line (or each record unit) and extract the corresponding fields;

[0085] Data cleaning and transformation: For text fields, remove extra spaces or special characters; for numeric fields, ensure they are converted to the expected internal format during reading.

[0086] For example, sample fields include:

[0087] Game Name: Used to bind the parsed strategy information to the corresponding game. If the corresponding game does not yet exist, the "Add Game" process can be triggered later.

[0088] Level name: can be mapped to a subpage or sub-entry in the encyclopedia system;

[0089] Character / Class, Equipment, Items, Quest Name, Reward Description: Used to break down various elements in the game;

[0090] The main body of the guide may include text, image links, and operation steps, which will be used to present detailed content in the encyclopedia entry later.

[0091] Furthermore, based on predefined "field-term type" mapping rules, the system will convert or map the parsed field content into the corresponding term structure, for example:

[0092] Main game entry: For example, the "Game Name" field in Excel corresponds to the main encyclopedia entry;

[0093] Level-related entries: If a "level name" is detected, a new or updated entry for that level will be created in the encyclopedia system;

[0094] Sub-entries such as character, equipment, items, and quests: each is mapped to the corresponding category in the encyclopedia;

[0095] Body or description content: Mapped to the detailed description field or the rich text field of the entry.

[0096] Meanwhile, the system can automatically generate or read the unique identifier information of existing entries (such as entry ID), which facilitates subsequent merging and updates.

[0097] Furthermore, after completing the row-by-row parsing and term mapping of the Excel data, the system uses the term generation module (or directly calls the relevant API of the encyclopedia management module) to create or update the corresponding term data in the database in batches.

[0098] If a record is detected to match an existing term (e.g., the term ID is the same, or the game name + level name already exists), then enter update mode:

[0099] Incremental update: Only the fields that have changed (such as strategy descriptions, equipment descriptions, etc.) are updated, while the rest of the existing information is retained;

[0100] Version management: The system can record metadata such as the time and user of the update operation as needed, so as to trace or roll back in the future.

[0101] For auditing and tracking purposes, while writing to the database, the system can also use xlwt or other write libraries to record the processing results to a log file or intermediate table, including a list of successfully processed terms, update patterns, reasons for failures, etc.

[0102] Furthermore, in some examples, after the term generation (or update) is completed, if the system detects that new levels, new characters, or new equipment do not yet exist or need to be revised for the knowledge graph entities, it can encapsulate the corresponding structured information into a "graph update request" and send it to the knowledge graph maintenance module through a message queue.

[0103] Based on this update request, the knowledge graph maintenance module will incrementally create or merge entity nodes and relationships in the graph database to keep pace with the latest entry status in the encyclopedia system.

[0104] As can be seen from the above embodiments, in some implementations of this application, by utilizing Excel parsing tools and predefined mapping rules, batches of game strategy files can be efficiently converted into encyclopedia entry data, significantly reducing the workload of manual input. Simultaneously, the system can trigger synchronous updates to the knowledge graph during the writing or updating of entries, ensuring consistency between encyclopedia and graph data. In large-scale game strategy scenarios, this embodiment can significantly improve operational efficiency and provide rich and accurate structured data support for subsequent related recommendations and advanced searches.

[0105] In some embodiments, entity objects and semantic relationships corresponding to term data are constructed, and the entity objects and semantic relationships are encapsulated into an update request message, including:

[0106] Based on the generated term data, the corresponding game semantic element types are identified, and the term data is converted into entity objects with structured attributes according to the preset entity classification rules;

[0107] Construct semantic relationships between entity objects based on their associations in the game's semantic hierarchy;

[0108] Encapsulate entity objects and semantic relationships to generate data structures that meet the requirements of the knowledge graph update interface;

[0109] The encapsulated entity objects and semantic relationships are sent as update request messages to the message queue so that the knowledge graph maintenance module can perform incremental update operations on the knowledge graph data.

[0110] Specifically, in this embodiment, the encyclopedia management module or the term generation module has obtained term data in structured or semi-structured form. This data includes various fields such as game name, level name, character, equipment, skills, items, quests, and NPCs. The system parses and categorizes each term data according to predefined "entity classification rules," for example:

[0111] If "game name" is detected in the field, the data entry will be identified as an entity of type "Game".

[0112] If a "level name" is detected, it is converted to a "Level" type entity;

[0113] If a field related to "role" or "occupation" is detected, it is converted to a "Role" type entity;

[0114] The same applies to other entity types (such as "equipment", "skills", "items" etc.).

[0115] After completing the parsing and matching, the system will assign a unique identifier to each entity object (based on term ID, automatically generated UUID, etc.) and store the parsed attribute values ​​(such as game publisher, level difficulty, equipment rarity, etc.) in structured attribute fields, thereby constructing an entity object data structure that meets the requirements of the knowledge graph pattern.

[0116] Furthermore, in this embodiment, the system constructs corresponding relationship types based on the associations between entity objects at the game's semantic level. For example:

[0117] "BelongsTo" relationship: If "Level A corresponds to Game X" is identified in the term data, then the relationship "Level A belongs to Game X" is generated;

[0118] "ApplicableTo" relationship: If equipment E is only applicable to a specific character R, the system automatically generates the relationship "Equipment E is applicable to character R";

[0119] "AssociatedWith" relationship: When a task T and an item D are associated with each other or need to be used together, the relationship "task T associated with item D" can be generated.

[0120] These relationship types are determined by the system's business requirements or predefined graph patterns. If the parsed fields indicate a relationship between a character and equipment, a character and a story node, or a quest and an NPC, the corresponding logic can be called to generate a "semantic relationship" object.

[0121] During the relationship generation process, the system records the main entity, the object entity, and associated attributes (such as frequency of occurrence, priority, recommendation degree, etc.) of the relationship to ensure that the relationship can be quickly queried and analyzed in the knowledge graph later.

[0122] Furthermore, once all entity objects and their semantic relationships have been constructed, the system encapsulates the entity object and relationship information into a unified data package according to the interface requirements of the knowledge graph maintenance module. This typically uses JSON or other extensible markup formats and includes the following key information:

[0123] List of entity objects: including entity type, entity name (or identifier), entity attribute fields and their values;

[0124] Relationship list: includes relationship type (such as "belongs to", "applies to", "associated with"), unique identifiers of the two entities and their associated attributes.

[0125] To maintain decoupling from the backend knowledge graph maintenance module, the system sends the encapsulated update request message to a pre-agreed message queue (such as "GraphUpdateQueue"), so that the knowledge graph maintenance module can perform the corresponding incremental update operation after listening to the message.

[0126] Furthermore, after packaging all entity objects and semantic relationships, the system will write this update request message to the message queue, along with necessary identification information (such as batch number, operating user, timestamp, etc.).

[0127] After consuming the update request from the message queue, the knowledge graph maintenance module can further determine whether to create a new node / relationship or merge and update an existing node / relationship based on the entity and relationship content, thereby achieving real-time or near real-time maintenance of the existing game domain knowledge graph.

[0128] If the update is successful, the knowledge graph maintenance module can record the receipt information in the queue or log system so that the encyclopedia management module can query the processing result of the incremental update.

[0129] As can be seen from the above embodiments, in some implementations of this application, by converting term data into a structure of "entity objects" and "semantic relationships," and then sending it to the knowledge graph maintenance module using a message queue, dynamic maintenance and upgrading of the game domain knowledge graph can be achieved. For different types of game semantic elements (games, levels, characters, equipment, skills, tasks, etc.), the system can flexibly classify and define relationships, facilitating subsequent graph-based retrieval, association recommendation, and reasoning analysis, thereby improving the usability and scalability of game strategy information.

[0130] In some embodiments, incremental updates are performed on knowledge graph data according to a predefined knowledge graph pattern to create or update game-related entity nodes and semantic relationships between entity nodes, including:

[0131] Based on the entity objects and semantic relationships in the update request message, the received entity types and relationship types are matched and verified according to the predefined knowledge graph pattern;

[0132] Existence checks are performed on entity objects in the knowledge graph. If the corresponding entity node does not exist, a new entity node is created and its attribute information is written. If it already exists, the node attributes are updated or merged based on the attribute changes.

[0133] Based on the semantic relationships between entity objects, determine whether a corresponding edge relationship already exists in the knowledge graph. If it does not exist, create a new relationship edge and set the associated attributes. If it already exists, update the attribute values ​​of the relationship edge.

[0134] Specifically, in this embodiment, the knowledge graph maintenance module continuously listens to a message queue (e.g., "GraphUpdateQueue") or a specific exposed interface to receive incremental update request messages;

[0135] When a new update request message appears in the message queue, the knowledge graph maintenance module will pop it (or consume it) and perform preliminary parsing:

[0136] Extract the list of entity objects and the list of relationships;

[0137] Verify the metadata in the message (such as batch number, source module, message format version, etc.) to ensure that it conforms to the communication protocol defined by the system.

[0138] Furthermore, after parsing, the knowledge graph maintenance module matches and verifies the "entity type" and "relationship type" carried in the message according to a predefined knowledge graph schema. For example:

[0139] Entity type matching: Determine whether "Game", "Level", "Role", "Equipment", "NPC", etc. in the message match the entity types registered in the graph pattern; if an unmatched entity type is found, it can be logged in the exception log or fault tolerance can be performed;

[0140] Relationship type matching: For example, "BelongsTo", "ApplicableTo", and "AssociatedWith" must also match the existing relationship types in the graph.

[0141] For entity objects that pass the matching verification, the knowledge graph maintenance module checks whether a corresponding node already exists in the graph database (such as Neo4j, ArangoDB, etc.):

[0142] Node determination criteria: The graph can be queried based on the unique identifier of the entity object (such as ID or name + type combination);

[0143] If the node does not exist, create it: If no corresponding node is detected, add the node to the graph and write the node attributes (such as game name, level difficulty, publisher information, etc.).

[0144] If an attribute already exists, update or merge it: If a corresponding node already exists in the graph, update or merge the node's attributes according to the attribute fields in the update request, such as updating the character's "health value" or "equipment level".

[0145] Furthermore, after processing the entity objects, the knowledge graph maintenance module performs the following operations for each relation entry based on the "relationship list" carried in the message:

[0146] Query existing edge relationships: Determine in the graph database whether a relationship of the same type already exists between two entity nodes;

[0147] If the relationship does not exist, a new edge will be created: If the relationship does not exist, the system will create a new edge and write associated attributes (such as "number of occurrences", "weight", "optional conditions", etc.).

[0148] If the relationship already exists, update the associated attributes: If the relationship already exists, modify or merge the attribute values ​​provided in this update request, such as resetting or accumulating the "association degree" or "priority".

[0149] In certain scenarios (such as batch importing game strategy content from Excel), a large number of entity objects and relationships may need to be updated within the same time period. To avoid excessively frequent operations on the graph database, this embodiment can centrally process all parsed update requests:

[0150] One-time validation: First, perform type and attribute matching validation on all entities and relationships;

[0151] Create or update nodes and relationships: Based on the verification results, create / update nodes and relationships in batches;

[0152] Reduce interaction overhead: This can significantly reduce the number of database connections and improve overall processing efficiency.

[0153] Furthermore, after processing is complete, the knowledge graph maintenance module can generate a receipt message indicating the operation result. This may include a list of entities / relationships that were successfully updated, a list of records that were skipped or encountered errors, etc.

[0154] The receipt message can be written back to the original message queue or notified to the business module so that subsequent business processes can be informed in a timely manner that the map has been updated.

[0155] If an anomaly is encountered (such as an unmatchable entity type, missing attributes, etc.), detailed error information can be recorded in the receipt message or log system so that administrators or operations and maintenance personnel can investigate and handle it.

[0156] Furthermore, in some examples, the message queue acts as an "intermediate decoupling layer": after the encyclopedia management module or Excel parsing module finishes processing the term data, it publishes the entity and relation update information to the message queue, and the knowledge graph maintenance module consumes the information from the queue before performing the update.

[0157] This asynchronous processing mode can effectively improve system scalability: the front-end encyclopedia module or data parsing module does not need to be tightly coupled with the graph database, and only needs to output update request messages according to the agreed format; while the knowledge graph maintenance module can independently arrange batch updates or handle conflicts, greatly improving the overall efficiency and reliability of the system.

[0158] As can be seen from the above embodiments, in some implementations of this application, by performing matching verification on the entity type and relation type in the incremental update request message, and creating or updating the corresponding entity nodes and relation edges in the graph database, the synchronization and improvement of game strategy-related data at the knowledge graph level can be ensured. This incremental update process not only guarantees the consistency between term data and graph data, but also provides a richer and more real-time knowledge foundation for subsequent game strategy retrieval, deep association analysis, and recommendation scenarios.

[0159] In some embodiments, based on the generated term data and entity information, a visual editing interface is provided for users to configure the encyclopedia page structure by dragging and dropping, generating a page rendering configuration file associated with the term data, including:

[0160] The front-end page presents a visual editing interface containing various page components;

[0161] Responding to the user's drag-and-drop operation in the visual editing interface, the system selects components and combines them into a page structure, and binds the selected components to term data or entity information;

[0162] Based on the user configuration results, a page rendering configuration file describing the page structure and data binding relationships is generated;

[0163] The page rendering configuration file is stored in the database and associated with the corresponding term identifier or encyclopedia page identifier so that it can be dynamically retrieved and the front-end rendering and display can be completed when the page is accessed.

[0164] Specifically, in this embodiment, when a user opens the front-end page of the game encyclopedia management platform, the system will first present a visual editing interface to the user; this interface contains a variety of predefined component options (such as text blocks, image blocks, video areas, tables, and visualization components of relationships, etc.), and each component has configurable attributes (such as size, position, and data types that can be bound, etc.); the user can drag and drop the required components from the component panel to the corresponding position in the editing area in this interface to form the initial layout structure of the page.

[0165] When a user drags and drops a component (such as a text block) into the page layout, the system will display the component's configurable options on the right or in a pop-up window, including:

[0166] Data source selection: Users can choose to bind this component to specific term data or entity information; for example, mapping the "Game Introduction" field to a text component to dynamically display the introduction of the current game on the page;

[0167] Style and appearance: Users can configure text size, alignment, line spacing, etc.; for image components, they can configure width, height, scaling, margins, etc.

[0168] Interaction logic: If a component needs to support interactive operations such as click navigation and hover tooltips, it can be configured here.

[0169] Users can repeat the above operations to bind different keyword data fields or relationship attributes (such as character information, equipment list, key level information, etc.) to multiple components, thereby forming rich text content or visual charts and other display modules.

[0170] Furthermore, after the user completes component drag-and-drop and attribute binding, the system automatically generates a configuration file describing the page layout and data binding relationship, typically in JSON or XML format. This configuration file includes:

[0171] Component list: Records information such as the type, position, and size of each component;

[0172] Data source binding: Maps the term fields or entity node attributes bound to each component;

[0173] Rendering logic: such as the hierarchical relationship between components, whether they need to be displayed in conjunction or dynamically refreshed, etc.

[0174] The system will then associate the configuration file with the corresponding term identifier (or encyclopedia page identifier) ​​and store it in the database (or a specific configuration repository).

[0175] For example, insert a record into the "page_config" table, which includes fields such as "page_id", "config_file_url", and "created_time". If the same game encyclopedia has multiple page layouts, they can be distinguished or managed based on page identifiers.

[0176] Furthermore, when other users or the same user browse the game encyclopedia, the front-end page will first retrieve the corresponding configuration file from the database based on the accessed term or page identifier;

[0177] The front-end rendering engine obtains relevant term data or entity information (such as game name, level list, character equipment details, etc.) from the back-end in real time according to the definition and binding relationship of each component in the configuration file.

[0178] The final result is a visual encyclopedia entry displayed on the page. If the relevant term data or graph information changes, the system can retrieve and render the latest content again without modifying the front-end code.

[0179] In some examples, the system may also include the following functionalities:

[0180] Version management: The system can generate a new version configuration each time a user edits the layout, so as to retrospectively or compare the page effects of different versions;

[0181] Automatic preview: Before you finish editing, you can click the "Preview" button and the system will render a preview interface based on the current configuration, allowing you to adjust the layout in time.

[0182] Multi-device adaptation: In certain implementations, adaptive layouts for mobile or large-screen devices can also be supported by adding responsive properties to the configuration file.

[0183] As can be seen from the above embodiments, in some implementations of this application, a low-code or no-code visual editing interface helps users configure the encyclopedia page structure by dragging and dropping, and bind the selected components to existing entries or knowledge graph entity information. This process not only significantly reduces the technical threshold for front-end page development, but also allows the encyclopedia page to be updated in real time as data changes, significantly improving the maintainability and visualization of game strategy content.

[0184] In some embodiments, based on knowledge graph data and combined with user-input keywords and filtering conditions, semantic hierarchical parsing is performed to determine the target entity and related terms, and to output game strategy content and related information semantically related to the keywords, including:

[0185] Receive user input search requests, which include keywords and filtering conditions;

[0186] Based on the maintained knowledge graph data, semantic parsing is performed to identify the entity types corresponding to the user-input keywords, and graph path traversal is performed in combination with filtering conditions to determine the set of target entities semantically associated with the keywords.

[0187] Retrieve term data associated with the target entity set, and generate a result set containing game strategy content, relationships between entities, and recommendation information according to the preset display logic. Then, pass the result set to the front-end page for visualization.

[0188] Specifically, in this embodiment, the user inputs keywords and a series of optional filtering conditions through the front-end search interface, such as:

[0189] Keywords: "Fire Mage Equipment"

[0190] Filtering criteria: such as game name (or ID) is "XX Game", character type is limited to "Mage", equipment rarity is greater than a certain threshold, etc.

[0191] The system backend will package the retrieval request into a query object, which includes the text information required for keyword parsing and structured filtering fields, and pass it to the knowledge graph retrieval module (or search engine component).

[0192] Furthermore, after receiving the query object, the knowledge graph retrieval module will first perform semantic analysis on the keyword "fire mage equipment". Its core objective is to identify the possible character entity categories corresponding to "fire mage" and the equipment entity types corresponding to "equipment".

[0193] In this process, the system may employ various technical methods (such as part-of-speech tagging, entity naming recognition, and synonym expansion) to map keywords to corresponding entity types or attribute ranges in the knowledge graph.

[0194] Character type: Determine whether "Fire Mage" falls under the category of character or class;

[0195] Equipment type: Determines the equipment entities that the user intends to retrieve that are applicable to or associated with the character;

[0196] Filtering criteria: Include "XX game", "rarity" or other restrictions in the subsequent query logic.

[0197] Furthermore, after determining the entity type corresponding to the keyword, the system performs a graph path traversal or query based on the pre-maintained knowledge graph and the filtering conditions. The specific process may include:

[0198] Locate the starting entity: Filter out the unique node or set of nodes for the game in the knowledge graph based on "XX Game";

[0199] Character matching: Starting from this game node, traverse along the "character" or "class" relationship to find character nodes that match the "fire mage" attribute;

[0200] Equipment Association: Search for all equipment nodes associated with a character node along the "ApplicableTo" relationship or other defined relationship types;

[0201] Attribute filtering: For the found equipment nodes, further determine whether their rarity or other attributes meet the filtering conditions, and leave the final set of target entities.

[0202] Furthermore, after obtaining the target entity set, the system will query the encyclopedia entries associated with these entity nodes. For example:

[0203] Equipment-related entries: Search for the "equipment" entry's introduction, attribute description, strategy guide, etc. in the encyclopedia database or entry management module;

[0204] Related recommendations: Expandable search for "skills that can be paired with this equipment", "strategy chapters related to the fire mage", "related NPCs or quests", etc. Related recommendations are enabled by default if users have such needs;

[0205] Based on the preset display logic or template format, the system combines all the retrieved term information and graph relationships into a result set object (which may include various formats such as JSON and HTML). This result set will cover multiple dimensions such as equipment information, character information, strategy guides, and graph recommendations.

[0206] Finally, the system passes the result set to the front end for rendering or display. Users can view it directly on the results page.

[0207] A list of equipment that matches the keyword "Flame Mage Equipment" and meets the filtering criteria (game name "XX Game", equipment rarity, etc.);

[0208] A diagram showing the relationship between equipment and elements such as characters and quests (if the system provides a visualization graph component).

[0209] Further recommendations include other equipment for the same character, or strategy chapters related to the Fire Mage, to help users explore further.

[0210] In some examples, if new equipment or character information is subsequently written into the knowledge graph, the system can use an incremental update mechanism to ensure that the latest equipment information or character relationships are automatically included when searching for similar keywords in the next search. Users can also dynamically adjust keywords or filter conditions during the search process, and the system will re-execute the search and update the results display in real time.

[0211] As can be seen from the above embodiments, in some implementations of this application, multi-level semantic parsing of user-input keywords and filtering conditions using knowledge graphs can more accurately locate target entities and output related terms or recommendation information, thereby helping users quickly obtain the game strategy content they want and discover more potentially useful information through the association relationships of the graph structure. This method is significantly superior to traditional pure text keyword matching methods, and can greatly improve the accuracy of game strategy retrieval and user experience.

[0212] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0213] Figure 2 This is a schematic diagram of the structure of the game strategy retrieval device based on knowledge graph structured management provided in this application embodiment. Figure 2 As shown, the game strategy retrieval device based on knowledge graph structured management includes:

[0214] Module 201 is used to respond to the request for new game information, construct a data object containing the basic attributes of the new game, encapsulate the data object as a message, and send it to the backend system through a message queue to trigger the encyclopedia entry initialization operation;

[0215] The parsing module 202 is used to read the structured file containing game strategy information uploaded by the user, parse the fields in the structured file, and map the fields to the corresponding term data;

[0216] The encapsulation module 203 is used to write term data into the database, construct entity objects and semantic relationships corresponding to the term data, and encapsulate the entity objects and semantic relationships into an update request message.

[0217] Update module 204 is used to respond to update request messages, incrementally update knowledge graph data according to predefined knowledge graph patterns, and create or update game-related entity nodes and semantic relationships between entity nodes.

[0218] The generation module 205 is used to provide a visual editing interface for users to configure the encyclopedia page structure by dragging and dropping based on the generated term data and entity information, and to generate a page rendering configuration file associated with the term data;

[0219] Output module 206 is used to perform semantic hierarchical parsing based on knowledge graph data, combined with user-input keywords and filtering conditions, to determine the target entity and related terms, and output game strategy content and related information that are semantically related to the keywords.

[0220] In some embodiments, Figure 2 The construction module 201 sends messages to a preset message queue to achieve asynchronous communication between the front-end request processing module and the back-end encyclopedia processing module. The back-end encyclopedia processing module listens to the message queue. When a message is received, it automatically performs the initialization operation of the encyclopedia entry. After the encyclopedia entry initialization is completed, it generates entry identification information and records the initialization status. The initialization operation of the encyclopedia entry includes creating a main entry in the database corresponding to the new game and writing the main entry into the basic attribute information of the new game.

[0221] In some embodiments, Figure 2 The parsing module 202 receives structured files uploaded by users through the front-end interface or API and stores the structured files in a temporary storage path; it performs format validation on the structured files, including file structure, header field naming, data type, and integrity. If the validation fails, it returns an error message; after the validation passes, it parses the data content in the structured files and extracts multiple field information related to the game; based on the mapping rules between fields and system predefined term types, it converts the extracted field content into the corresponding term data structure.

[0222] In some embodiments, Figure 2 The encapsulation module 203 identifies the corresponding game semantic element type based on the generated term data and converts the term data into entity objects with structured attributes according to the preset entity classification rules; constructs semantic relationships between entity objects based on the association between entity objects in the game semantic hierarchy; encapsulates the entity objects and semantic relationships to generate a data structure that meets the requirements of the knowledge graph update interface; and sends the encapsulated entity objects and semantic relationships as update request messages to the message queue so that the knowledge graph maintenance module can perform incremental update operations on the knowledge graph data.

[0223] In some embodiments, Figure 2 The update module 204 matches and verifies the received entity type and relationship type according to the entity object and semantic relationship in the update request message and in accordance with the predefined knowledge graph pattern; it performs existence detection on the entity object in the knowledge graph. If the corresponding entity node does not exist, it creates a new entity node and writes attribute information. If it already exists, it performs node attribute update or merging operations according to attribute changes; based on the semantic relationship between entity objects, it determines whether the corresponding edge relationship already exists in the knowledge graph. If it does not exist, it creates a relationship edge and sets associated attributes. If it already exists, it updates the attribute values ​​of the relationship edge.

[0224] In some embodiments, Figure 2 The generation module 205 presents a visual editing interface containing various page components on the front-end page; responding to the user's drag-and-drop operation in the visual editing interface, it selects components and combines them into a page structure, and binds the selected components with term data or entity information; based on the user configuration results, it generates a page rendering configuration file describing the page structure and data binding relationship; it stores the page rendering configuration file in the database and establishes an association with the corresponding term identifier or encyclopedia page identifier so that it can be dynamically retrieved and the front-end rendering display can be completed when the page is accessed.

[0225] In some embodiments, Figure 2 The output module 206 receives the user's input search request, which includes keywords and filtering conditions; based on the maintained knowledge graph data, it performs semantic parsing to identify the entity type corresponding to the user's input keywords, and performs graph path traversal in combination with the filtering conditions to determine the target entity set semantically associated with the keywords; it retrieves the term data associated with the target entity set, and generates a result set containing game strategy content, inter-entity relationships, and recommendation information according to the preset display logic, and transmits the result set to the front-end page for visualization display.

[0226] 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.

[0227] 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 3As 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.

[0228] 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.

[0229] 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.

[0230] 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.

[0231] 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.

[0232] 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.

[0233] 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.

[0234] 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.

[0235] 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. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.

[0236] 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.

[0237] Furthermore, the functional units in the various embodiments of this application 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.

[0238] 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.

[0239] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application are 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 guide search method based on knowledge graph structured management, characterized in that, The method comprises the following steps: In response to a new game information request, a data object containing the basic attributes of the new game is constructed, and the data object is encapsulated as a message and sent to a backend system through a message queue to trigger a encyclopedia entry initialization operation; A structured file uploaded by a user and containing game guide information is read, fields in the structured file are parsed, and the fields are mapped to corresponding entry data; The entry data is written into a database, an entity object and semantic relationships corresponding to the entry data are constructed, and the entity object and semantic relationships are encapsulated as an update request message; In response to the update request message, the knowledge graph data is incrementally updated according to a predefined knowledge graph pattern, and entity nodes related to the game and semantic relationships between the entity nodes are created or updated; Based on the generated entry data and entity information, a visual editing interface is provided for a user to configure an encyclopedia page structure in a drag-and-drop manner, and a page rendering configuration file associated with the entry data is generated; Based on the knowledge graph data, in combination with a keyword and filtering conditions input by a user, semantic level analysis is performed to determine a target entity and related entries for retrieval, and game guide content and associated information semantically related to the keyword are output; The method comprises the following steps: According to the entity object and semantic relationships in the update request message, the received entity types and relationship types are matched and verified according to the predefined knowledge graph pattern; Existence detection is performed on the entity object in the knowledge graph, if the corresponding entity node does not exist, a new entity node is created and attribute information is written, if the entity node already exists, node attribute update or merging operations are performed according to attribute changes; Based on the semantic relationships between the entity objects, it is judged whether corresponding edge relationships exist in the knowledge graph, if not, a new relationship edge is created and associated attributes are set, if they exist, the attribute values of the relationship edge are updated.

2. The method of claim 1, wherein, The method comprises the following steps: The message is sent to a preset message queue to realize asynchronous communication between a front-end request processing module and a back-end encyclopedia processing module; The message queue is listened to in the back-end encyclopedia processing module, when the message is received, the initialization operation of the encyclopedia entry is automatically performed, and after the initialization of the encyclopedia entry is completed, entry identification information is generated and the initialization state is recorded; The initialization operation of the encyclopedia entry comprises creating a main entry corresponding to the new game in the database, and writing the main entry into the basic attribute information of the new game.

3. The method of claim 1, wherein, The method comprises the following steps: A structured file uploaded by a user through a front-end interface or interface is received, and the structured file is stored in a temporary storage path; Performing a format checking operation on the structured file, the checking content including file structure, table header field naming, data type and integrity, and returning an error prompt information if the checking fails; After the checking passes, parsing the data content in the structured file, and extracting a plurality of field information related to the game; Based on the mapping rules between the fields and the system pre-defined term types, the extracted field content is converted into corresponding term data structure.

4. The method of claim 1, wherein, The entity object and semantic relationship corresponding to the term data are constructed, and the entity object and semantic relationship are encapsulated as an update request message, including: Based on the generated term data, identifying the corresponding game semantic element type, and converting the term data into an entity object with structured attributes according to the preset entity classification rules; According to the association relationship between the entity objects in the game semantic hierarchy, the semantic relationship between the entity objects is constructed; The entity object and semantic relationship are data encapsulated to generate a data structure conforming to the knowledge graph update interface requirements; The encapsulated entity object and semantic relationship are sent to the message queue as an update request message, so that the knowledge graph maintenance module performs incremental update operation of the knowledge graph data.

5. The method of claim 1, wherein, According to the generated term data and entity information, a visual editing interface is provided for users to configure the encyclopedia page structure in a drag-and-drop manner, and a page rendering configuration file associated with the term data is generated, including: A visual editing interface containing a plurality of page components is presented on the front end page; In response to the drag-and-drop operation of the user in the visual editing interface, the components are selected and combined into a page structure, and the selected components are bound to the term data or entity information; According to the user configuration result, a page rendering configuration file describing the page structure and data binding relationship is generated; The page rendering configuration file is stored in the database and associated with the corresponding term identifier or encyclopedia page identifier, so as to dynamically pull and complete the front end rendering display when the page is accessed.

6. The method of claim 1, wherein, Based on the knowledge graph data, combined with the keywords and filtering conditions input by the user, the semantic level analysis is performed to determine the retrieval target entity and related term, and the game strategy content and associated information related to the keyword semantics are output, including: Receiving a retrieval request input by a user, the retrieval request including a keyword and a filtering condition; Based on the maintained knowledge graph data, performing semantic analysis operation, identifying the entity type corresponding to the user input keyword, and combining the filtering condition to perform graph path traversal to determine the target entity set associated with the keyword semantics; Retrieving the term data associated with the target entity set, and generating a result set containing game strategy content, entity association relationship and recommendation information according to the preset display logic, and delivering the result set to the front end page for visual display. 7.A game guide search device based on knowledge graph structured management, characterized in that, Including: The construction module is used for responding to the new game information request, constructing a data object containing the basic attributes of the new game, and encapsulating the data object as a message and sending it to the backend system through the message queue to trigger the encyclopedia term initialization operation; The parsing module is configured to read a structured file uploaded by a user and containing game guide information, parse fields in the structured file, and map the fields to corresponding entry data; The packaging module is configured to write the entry data into a database, construct entity objects and semantic relationships corresponding to the entry data, and package the entity objects and semantic relationships as an update request message; The updating module is configured to respond to the update request message, incrementally update knowledge graph data according to a predefined knowledge graph mode, and create or update entity nodes related to a game and semantic relationships between the entity nodes; The generating module is configured to provide a visual editing interface for a user to configure a wiki page structure in a drag-and-drop manner according to the generated entry data and entity information, and generate a page rendering configuration file associated with the entry data; The output module is configured to perform semantic hierarchical analysis based on the knowledge graph data, in combination with a keyword and filtering conditions input by a user, determine a target entity and related entries, and output game guide content and associated information that are semantically related to the keyword. The updating module is configured to match and verify entity types and relationship types received according to entity objects and semantic relationships in the update request message according to a predefined knowledge graph mode; The updating module is configured to perform existence detection on the entity objects in the knowledge graph, create an entity node and write attribute information if a corresponding entity node does not exist, or perform node attribute updating or merging operations according to attribute changes if the entity node already exists; and determine whether corresponding edge relationships exist in the knowledge graph based on semantic relationships between the entity objects, create a relationship edge and set associated attributes if the edge relationships do not exist, or update attribute values of the relationship edge if the edge relationships already exist.

8. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 8. The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

Images